SRCU: Number of outstanding callbacks

SRCU: Number of outstanding callbacks

[Dmitriy V'jukov]

I've read Paul McKenney's article about SRCU:
http://lwn.net/Articles/202847

And I am curious as to why only single outstanding SRCU callback per
thread is allowed. The problem with RCU is that it allows basically
unbounded number of outstanding callbacks, so why just not bound
number of outstanding callbacks in SRCU? Memory blocks are frequently
quite small, so that subsystem can tolerate up to let's say 1000
pending memory blocks. Restriction on single pending callback looks
quite severe (may cause unnecessary blocking), so why not provide:
int init_srcu_struct(struct srcu_struct *sp, int
limit_of_pending_callbacks);
?
While limit is not reached call_srcu() is non blocking, otherwise it
waits for grace period (behaves like synchronize_srcu()). I think in
many situations call_srcu() will be practically non-blocking (in
common case), while still guaranteeing bounded memory consumption.
Note that currently number of outstanding SRCU callbacks is
"unbounded" anyway (equal to number_of_threads), so changing number_of_threads
to number_of_threads+N must not have any bad consequences.
Or it's just not worth doing (because of the additional implementation
complexity)?
Thanks.

--
Best regards,
Dmitriy V'jukov

Re: SRCU: Number of outstanding callbacks

[Paul E. McKenney]

On Wed, Mar 11, 2009 at 10:48:24AM +0000, Dmitriy V'jukov wrote:
> I've read Paul McKenney's article about SRCU:
> http://lwn.net/Articles/202847
> 
> And I am curious as to why only single outstanding SRCU callback per
> thread is allowed. The problem with RCU is that it allows basically
> unbounded number of outstanding callbacks, so why just not bound
> number of outstanding callbacks in SRCU? Memory blocks are frequently
> quite small, so that subsystem can tolerate up to let's say 1000
> pending memory blocks. Restriction on single pending callback looks
> quite severe (may cause unnecessary blocking), so why not provide:
> int init_srcu_struct(struct srcu_struct *sp, int
> limit_of_pending_callbacks);
> ?
> While limit is not reached call_srcu() is non blocking, otherwise it
> waits for grace period (behaves like synchronize_srcu()). I think in
> many situations call_srcu() will be practically non-blocking (in
> common case), while still guaranteeing bounded memory consumption.
> Note that currently number of outstanding SRCU callbacks is
> "unbounded" anyway (equal to number_of_threads), so changing number_of_threads
> to number_of_threads+N must not have any bad consequences.
> Or it's just not worth doing (because of the additional implementation
> complexity)?
> Thanks.

The short answer is, as you guessed, because it is not (yet) worth doing.
This is at least in part because SRCU is not heavily used.

The philosophy behind the limitation is that the memory overhead of
the blocks is a small fraction of the memory required to represent
a thread.  As you say, there are a number of other strategies that can
be pursued, but the current strategy has the advantage of simplicity.
In particular, the current strategy does not require a failure return
from an as-yet-nonexistent call_srcu().  Handling such a failure return
is certainly possible, but someone would have to show me an extremely
good reason for putting up with this.  ;-)

							Thanx, Paul

Re: SRCU: Number of outstanding callbacks

[Dmitriy V\'jukov]

Paul E. McKenney <paulmck <at> linux.vnet.ibm.com> writes:

> The short answer is, as you guessed, because it is not (yet) worth doing.
> This is at least in part because SRCU is not heavily used.
> 
> The philosophy behind the limitation is that the memory overhead of
> the blocks is a small fraction of the memory required to represent
> a thread.  As you say, there are a number of other strategies that can
> be pursued, but the current strategy has the advantage of simplicity.
> In particular, the current strategy does not require a failure return
> from an as-yet-nonexistent call_srcu().  Handling such a failure return
> is certainly possible, but someone would have to show me an extremely
> good reason for putting up with this.  


Yes, I've noticed the extreme simplicity of the current synchronize_srcu().
As for failure return from call_srcu(), I think it's possible to just call
synchronize_srcu() from inside call_srcu() if the latter encounters any errors.
Anyway call_srcu() will be "sometimes blocking" because of the limit on number
of outstanding callbacks, so this must not be a problem.


--
Best regards,
Dmitriy V'jukov