[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150803135532.GB25554@lerouge>
Date: Mon, 3 Aug 2015 15:55:34 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
Christoph Lameter <cl@...ux.com>,
Ingo Molnar <mingo@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 05/10] nohz: New tick dependency mask
On Mon, Aug 03, 2015 at 03:29:58PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 03, 2015 at 03:09:39PM +0200, Frederic Weisbecker wrote:
>
> > > 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.
>
> Urgh, I missed that. But yes, I suppose that's ok seeing how we result
> in a smaller interface.
>
> I was going to say that with a bit of luck GCC could optimize it, but
> its not inline so no it cannot.
I might inline all these set_dep() things to introduce static keys on these
APIs.. But the kick itself will remain real calls.
Ok how about tick_nohz_set_dep_nmi() so that we know exactly what's the purpose
here. Still a long function name but it's clear.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists