linux-kernel - Re: SRCU: Number of outstanding callbacks

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]

Date:	Wed, 11 Mar 2009 07:43:27 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	"Dmitriy V'jukov" <dvyukov@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: SRCU: Number of outstanding callbacks

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