To: linux-kernel@vger.kernel.org
From: "Dmitriy V'jukov" <dvyukov@gmail.com>
Subject: SRCU: Number of outstanding callbacks
Date: Wed, 11 Mar 2009 10:48:24 +0000 (UTC)
Message-ID: <loom.20090311T104615-980@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1470
Lines: 27

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/