linux-kernel - Re: [PATCH RFC -tip 0/4] v3 RCU cleanups and simplified preemptable RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090824155910.GF6677@linux.vnet.ibm.com>
Date:	Mon, 24 Aug 2009 08:59:10 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, josht@...ux.vnet.ibm.com,
	dvhltc@...ibm.com, niv@...ibm.com, tglx@...utronix.de,
	rostedt@...dmis.org
Subject: Re: [PATCH RFC -tip 0/4] v3 RCU cleanups and simplified
	preemptable RCU

On Mon, Aug 24, 2009 at 09:21:59AM +0200, Peter Zijlstra wrote:
> On Sat, 2009-08-22 at 13:52 -0700, Paul E. McKenney wrote:
> > 
> > o       Rename variables and functions so that RCU-sched is an
> >         underlying definition, along with RCU-bh and (when so
> >         configured) RCU-preempt.  RCU then maps to either RCU-sched
> >         or RCU-preempt, depending on configuration.
> 
> Nice, but we're not quite there yet it seems, since RCU-preempt isn't
> available outside of TREE_PREEMPT_RCU afaiks.
> 
> That is, I'm still hoping for the day that generic code can do:
> 
>   rcu_preempt_read_lock();
> 
> 
>   call_rcu_preempt(&my_rcu_thing);
>   rcu_preempt_read_unlock();
> 
> And have it work like expected, this would, I think, remove much of the
> need for SRCU.

Longer term, CONFIG_PREEMPT will imply CONFIG_TREE_PREEMPT_RCU and
!CONFIG_PREEMPT will imply CONFIG_TREE_RCU.  This will reduce the
number of combinations in need of testing.  So then the question is
"what does call_rcu_preempt() mean in !CONFIG_PREEMPT"?

If we permit things like mutex_lock(), we have the possibility of
indefinitely extended RCU read-side critical sections, which leads us to:

> The thing I've talked about earlier is an extension of this where you
> can create multiple RCU domains along the lines of:
> 
>   struct rcu_preempt_domain my_domain;
> 
>   rcu_preempt_init(&my_domain);
> 
> 
> and
> 
>   rcu_preempt_read_lock(&my_domain);
> 
>   call_rcu_preempt(&my_domain, &my_rcu_head);
>   rcu_preempt_read_unlock(&my_domain);

This is in fact what SRCU does.  Of course, it also requires
that the return value from rcu_preempt_read_lock() be passed into
rcu_preempt_read_unlock() (AKA srcu_read_lock() and srcu_read_unlock()),
in order to handle the case where there are a number of nested SRCU
read-side critical sections with different domains.  I suppose that we
could instead dynamically allocate space for this information, but...

> Which would allow you to create smaller RCU domains for when you want
> faster grace periods due to less interference of other rcu users.

The other thing in -tip for this purpose is synchronize_rcu_expedited().

> Anyway, enough rambling, the patch-set does look very nice, and if time
> permits I'll try and go through the preempt-tree-rcu thing.

I would very much appreciate that!!!  My next patch set (hopefully later
today Pacific time) will fix CPU hotplug for the single-node-tree case,
with full support later this week.

							Thanx, Paul
--
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/