Re: [PATCH v3 7/9] KVM-GST: KVM Steal time accounting

[Glauber Costa]

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(&paravirt_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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/