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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 15:07:28 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> Cc: linux-kernel@...r.kernel.org Subject: Re: Kernel RCU: shrink the size of the struct rcu_head On Sun, Oct 18, 2009 at 07:29:18PM -0400, Mathieu Desnoyers wrote: > Hi Paul, > > I noticed that you already discussed the possibility of shrinking the > struct rcu_head by removing the function pointer. > (http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html) > > The ideas brought in so far require having per-callback lists, which > involves a bit of management overhead and don't permit keeping the > call_rcu() in cpu order. But please note that this is on the "Possibly Dubious Changes" list. ;-) > You might want to look into the Userspace RCU urcu-defer.c > implementation, where I perform pointer encoding to compact the usual > case, expected to be the same callback passed as parameter multiple > times in a row to call_rcu(). This is very typical with multiple free() > calls for different data structures next to each other. > > This typically keeps the size of the information to encode per callback > down to a minimum: the size of a single pointer. It would be good to > trace the kernel usage of call_rcu() to see if my assumption holds. > > I just thought I should tell you before you start looking at this > issue further. So the idea is to maintain a per-CPU queue of function pointers, but with the pointers on this queue encoded to save space, correct? If I understand correctly, the user-level rcu-defer implementation relies on the following: 1. It is illegal to call _rcu_defer_queue() within an RCU read-side critical section (due to the call to rcu_defer_barrier_thread() which in turn calls synchronize_rcu(). This is necessary to handle queue overflow. (Which appears to be why you introduce a new API, as it is legal to invoke call_rcu() from within an RCU read-side critical section.) 2. It is OK to wait for a grace period when a thread calls rcu_defer_unregister_thread() while exiting. In the kernel, this is roughly equivalent to the CPU_DYING notifier, which cannot block, thus cannot wait for a grace period. I could imagine copying the per-CPU buffer somewhere, though my experience with the RCU/CPU-hotplug interface does not encourage me in this direction. ;-) 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/
Powered by blists - more mailing lists