Re: [PATCH 05/10] nohz: New tick dependency mask

From: Frederic Weisbecker
Date: Mon Aug 03 2015 - 09:09:50 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/