linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID:  <loom.20090311T104615-980@post.gmane.org>
Date:	Wed, 11 Mar 2009 10:48:24 +0000 (UTC)
From:	Dmitriy V'jukov <dvyukov@...il.com>
To:	linux-kernel@...r.kernel.org
Subject:  SRCU: Number of outstanding callbacks

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

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