Messages in this thread | | | Date | Sat, 21 Feb 2015 17:43:43 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods |
| |
On Sat, Feb 21, 2015 at 05:08:52PM +0100, Peter Zijlstra wrote: > On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote: > > On 2/20/2015 9:43 AM, Peter Zijlstra wrote: > > >On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote: > > >>there's a few others as well that I'm chasing down... > > >>.. but the flip side, prior to running ring 3 code, why NOT do fast expedites? > > > > > >So my objections are twofold: > > > > > > - I object to fast expedites in principle; they spray IPIs across the > > > system, so ideally we'd not have them at all, therefore also not at > > > boot. > > > > > > Because as soon as the option exists, people will use it for other > > > things too. > > > > the option exists today in sysfs and kernel parameter... > > Yeah, Paul and me have been having this argument for a while now ;-)
Indeed we have. ;-)
And if expedited grace periods start causing latency issues in real-world workloads, I will address those issues.
In the meantime, one of the nice things about NO_HZ_FULL is that synchronize_sched_expedited() avoids IPIing CPUs having a single runnable task that is running in nohz_full mode. ;-)
Thanx, Paul
> > >And esp. in bootup code you can special case a lot of stuff; there's > > >limited concurrency esp. because userspace it not there yet. So we might > > >not actually need those sync calls. > > > > yeah I am going down that angle as well absolutely. > > but there are cases that may well be legit (or are 5 function calls deep into common code) > > Good ;-) >
| |