On Mon, Aug 03, 2015 at 02:57:17PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 23, 2015 at 06:42:10PM +0200, Frederic Weisbecker wrote:
> > +void tick_nohz_set_tick_dependency(enum tick_dependency_bit bit)
> > +{
> > +   unsigned long prev;
> > +
> > +   prev = __tick_nohz_set_tick_dependency(bit, &tick_dependency);
> > +   if (!prev)
> > +           tick_nohz_full_kick_all();
> > +}
> 
> > +void tick_nohz_set_tick_dependency_cpu(enum tick_dependency_bit bit, int 
> > cpu)
> > +{
> > +   unsigned long prev;
> > +   struct tick_sched *ts;
> > +
> > +   ts = per_cpu_ptr(&tick_cpu_sched, cpu);
> > +
> > +   prev = __tick_nohz_set_tick_dependency(bit, &ts->tick_dependency);
> > +   if (!prev)
> > +           tick_nohz_full_kick_cpu(cpu);
> > +}
> 
> > +/*
> > + * Local dependency must have its own flavour due to NMI-safe requirement
> > + * on perf.
> > + */
> 
> That doesn't make any sense:
> 
>   tick_nohz_set_tick_dependency_this_cpu();
> 
> (shees, you're nowhere near lazy enough, that's insane to type) is
> almost identical to:
> 
>   tick_nohz_set_tick_dependency_cpu(.cpu = smp_processor_id());
> 
> The only difference is a _very_ slight reduction in cost for computing
> the per-cpu offset.

But the local one must be NMI-safe. Now I can do:

    if (cpu == smp_processor_id())
        tick_nohz_full_kick() // NMI-safe
    else
        tick_nohz_full_kick_cpu(cpu); // not NMI-safe.

> 
> > +void tick_nohz_set_tick_dependency_this_cpu(enum tick_dependency_bit bit)
> > +{
> > +   unsigned long prev;
> > +   struct tick_sched *ts;
> > +
> > +   ts = this_cpu_ptr(&tick_cpu_sched);
> > +
> > +   prev = __tick_nohz_set_tick_dependency(bit, &ts->tick_dependency);
> > +   if (!prev)
> > +           tick_nohz_full_kick();
> > +}
> 
> 
> And on that naming; could we please shorten them, this is really
> ridiculous, it has 'tick' in it twice.
> 
> What's wrong with:
> 
>       tick_nohz_set_dep()
>       tick_nohz_set_dep_cpu()

Right.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to