| Message ID | 1309361388-30163-8-git-send-email-glommer@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 29 Jun 2011, Glauber Costa wrote: > This patch accounts steal time time in kernel/sched. > I kept it from last proposal, because I still see advantages > in it: Doing it here will give us easier access from scheduler > variables such as the cpu rq. The next patch shows an example of > usage for it. > > Since functions like account_idle_time() can be called from > multiple places, not only account_process_tick(), steal time > grabbing is repeated in each account function separatedely. > > Signed-off-by: Glauber Costa <glommer@redhat.com> > CC: Rik van Riel <riel@redhat.com> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > CC: Peter Zijlstra <peterz@infradead.org> > CC: Avi Kivity <avi@redhat.com> > CC: Anthony Liguori <aliguori@us.ibm.com> > CC: Eric B Munson <emunson@mgebm.net> Tested-by: Eric B Munson <emunson@mgebm.net>
On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote: > +static noinline bool touch_steal_time(int is_idle) That noinline is very unlucky there, > +{ > + u64 steal, st = 0; > + > + if (static_branch(¶virt_steal_enabled)) { > + > + steal = paravirt_steal_clock(smp_processor_id()); > + > + steal -= this_rq()->prev_steal_time; > + > + st = steal_ticks(steal); > + this_rq()->prev_steal_time += st * TICK_NSEC; > + > + if (is_idle || st == 0) > + return false; > + > + account_steal_time(st); > + return true; > + } > + return false; > +} > + > static void update_rq_clock_task(struct rq *rq, s64 delta) > { > s64 irq_delta; > @@ -3716,6 +3760,9 @@ void account_user_time(struct task_struct *p, > cputime_t cputime, > struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat; > cputime64_t tmp; > > + if (touch_steal_time(0)) > + return; Means we have an unconditional call here, even if the static_branch() is patched out. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/30/2011 06:54 PM, Peter Zijlstra wrote: > On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote: >> +static noinline bool touch_steal_time(int is_idle) > > That noinline is very unlucky there, > >> +{ >> + u64 steal, st = 0; >> + >> + if (static_branch(¶virt_steal_enabled)) { >> + >> + steal = paravirt_steal_clock(smp_processor_id()); >> + >> + steal -= this_rq()->prev_steal_time; >> + >> + st = steal_ticks(steal); >> + this_rq()->prev_steal_time += st * TICK_NSEC; >> + >> + if (is_idle || st == 0) >> + return false; >> + >> + account_steal_time(st); >> + return true; >> + } >> + return false; >> +} >> + >> static void update_rq_clock_task(struct rq *rq, s64 delta) >> { >> s64 irq_delta; >> @@ -3716,6 +3760,9 @@ void account_user_time(struct task_struct *p, >> cputime_t cputime, >> struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat; >> cputime64_t tmp; >> >> + if (touch_steal_time(0)) >> + return; > > Means we have an unconditional call here, even if the static_branch() is > patched out. Ok. I was under the impression that the proper use of jump labels required each label to be tied to a single location. If we make it inline, the same key would point to multiple locations, and we would have trouble altering all of the locations. I might be wrong, of course. Isn't it the case? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/30/2011 06:54 PM, Peter Zijlstra wrote: > On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote: >> This patch accounts steal time time in kernel/sched. >> I kept it from last proposal, because I still see advantages >> in it: Doing it here will give us easier access from scheduler >> variables such as the cpu rq. The next patch shows an example of >> usage for it. >> >> Since functions like account_idle_time() can be called from >> multiple places, not only account_process_tick(), steal time >> grabbing is repeated in each account function separatedely. >> > > That changelog is so going to frustrate someone trying to re-create your > thinking in a year's time. They really don't care about the last > proposals and the next patch. You're right. I'll review all changelogs and rewrite them as needed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/30/2011 06:54 PM, Peter Zijlstra wrote: > On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote: >> + if (static_branch(¶virt_steal_enabled)) { > > How is that going to compile on !CONFIG_PARAVIRT or !x86 in general? > Only x86-PARAVIRT will provide that variable. > > Good point. I'd wrap it into CONFIG_PARAVIRT. To be clear, the reason I did not put it inside CONFIG_PARAVIRT_TIME_ACCOUNTING, is because I wanted to have the mere display of steal time separated from the rest - unless, of course, you object this idea. Using CONFIG_PARAVIRT achieves this goal well. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2011-06-30 at 23:50 -0300, Glauber Costa wrote: > I was under the impression that the proper use of jump labels required > each label to be tied to a single location. If we make it inline, the > same key would point to multiple locations, and we would have trouble > altering all of the locations. I might be wrong, of course. Isn't it the > case? Nope, you can have as many patch sites per key as you want. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2011-06-30 at 23:53 -0300, Glauber Costa wrote: > On 06/30/2011 06:54 PM, Peter Zijlstra wrote: > > On Wed, 2011-06-29 at 11:29 -0400, Glauber Costa wrote: > >> + if (static_branch(¶virt_steal_enabled)) { > > > > How is that going to compile on !CONFIG_PARAVIRT or !x86 in general? > > Only x86-PARAVIRT will provide that variable. > > > > > > Good point. I'd wrap it into CONFIG_PARAVIRT. > To be clear, the reason I did not put it inside > CONFIG_PARAVIRT_TIME_ACCOUNTING, is because I wanted to have the mere > display of steal time separated from the rest - unless, of course, you > object this idea. > > Using CONFIG_PARAVIRT achieves this goal well. ia64 seems to also have CONFIG_PARAVIRT -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/sched.c b/kernel/sched.c index 3f2e502..c166863 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -75,6 +75,7 @@ #include <asm/tlb.h> #include <asm/irq_regs.h> #include <asm/mutex.h> +#include <asm/paravirt.h> #include "sched_cpupri.h" #include "workqueue_sched.h" @@ -528,6 +529,7 @@ struct rq { #ifdef CONFIG_IRQ_TIME_ACCOUNTING u64 prev_irq_time; #endif + u64 prev_steal_time; /* calc_load related fields */ unsigned long calc_load_update; @@ -1953,6 +1955,48 @@ void account_system_vtime(struct task_struct *curr) } EXPORT_SYMBOL_GPL(account_system_vtime); +#endif /* CONFIG_IRQ_TIME_ACCOUNTING */ + +static inline u64 steal_ticks(u64 steal) +{ + if (unlikely(steal > NSEC_PER_SEC)) + return steal / TICK_NSEC; + + return __iter_div_u64_rem(steal, TICK_NSEC, &steal); +} + +/* + * We have to at flush steal time information every time something else + * is accounted. Since the accounting functions are all visible to the rest + * of the kernel, it gets tricky to do them in one place. This helper function + * helps us. + * + * When the system is idle, the concept of steal time does not apply. We just + * tell the underlying hypervisor that we grabbed the data, but skip steal time + * accounting + */ +static noinline bool touch_steal_time(int is_idle) +{ + u64 steal, st = 0; + + if (static_branch(¶virt_steal_enabled)) { + + steal = paravirt_steal_clock(smp_processor_id()); + + steal -= this_rq()->prev_steal_time; + + st = steal_ticks(steal); + this_rq()->prev_steal_time += st * TICK_NSEC; + + if (is_idle || st == 0) + return false; + + account_steal_time(st); + return true; + } + return false; +} + static void update_rq_clock_task(struct rq *rq, s64 delta) { s64 irq_delta; @@ -3716,6 +3760,9 @@ void account_user_time(struct task_struct *p, cputime_t cputime, struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat; cputime64_t tmp; + if (touch_steal_time(0)) + return; + /* Add user time to process. */ p->utime = cputime_add(p->utime, cputime); p->utimescaled = cputime_add(p->utimescaled, cputime_scaled); @@ -3802,6 +3849,9 @@ void account_system_time(struct task_struct *p, int hardirq_offset, struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat; cputime64_t *target_cputime64; + if (touch_steal_time(0)) + return; + if ((p->flags & PF_VCPU) && (irq_count() - hardirq_offset == 0)) { account_guest_time(p, cputime, cputime_scaled); return; @@ -3839,6 +3889,8 @@ void account_idle_time(cputime_t cputime) cputime64_t cputime64 = cputime_to_cputime64(cputime); struct rq *rq = this_rq(); + touch_steal_time(1); + if (atomic_read(&rq->nr_iowait) > 0) cpustat->iowait = cputime64_add(cpustat->iowait, cputime64); else
This patch accounts steal time time in kernel/sched. I kept it from last proposal, because I still see advantages in it: Doing it here will give us easier access from scheduler variables such as the cpu rq. The next patch shows an example of usage for it. Since functions like account_idle_time() can be called from multiple places, not only account_process_tick(), steal time grabbing is repeated in each account function separatedely. Signed-off-by: Glauber Costa <glommer@redhat.com> CC: Rik van Riel <riel@redhat.com> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> CC: Peter Zijlstra <peterz@infradead.org> CC: Avi Kivity <avi@redhat.com> CC: Anthony Liguori <aliguori@us.ibm.com> CC: Eric B Munson <emunson@mgebm.net> --- kernel/sched.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 52 insertions(+), 0 deletions(-)