| 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
| ||
|
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/
Powered by blists - more mailing lists