Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods

[Paul E. McKenney]

On Fri, Feb 20, 2015 at 06:43:59PM +0100, 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.

There are only a few uses of expedited grace periods, despite their
having been in the kernel for some years.  So people do seem to be
exercising appropriate restraint here.

>    Because as soon as the option exists, people will use it for other
>    things too.
> 
>  - The proposed interface is very much exposed to everybody who wants
>    it; this again is wide open to (ab)use.
> 
>    Once it exists people will start to use, and before you know it we'll
>    always have that fast counter incremented and we're in IPI hell. Most
>    likely because someone was lazy and it seemed like a quick fix for
>    some stupid code.

I suppose that another way to keep it private would be to have the
declaration in both update.c and rcutorture.c.  This would mean that no
other file could invoke it, and should keep 0day happy.  It would mean
that the declarations would be duplicated, but worse things could happen.

> 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.

I expect that some could be rewritten, but it might not work well for
code common to boot and to runtime.


							Thanx, Paul

--
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/