Messages in this thread | | | Date | Tue, 4 Sep 2007 11:16:50 +0530 (IST) | From | Satyam Sharma <> | Subject | Re: [PATCH] Make rcutorture RNG use temporal entropy |
| |
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote: > > The locking used by get_random_bytes() can conflict with the > preempt_disable() and synchronize_sched() form of RCU. This patch changes > rcutorture's RNG to gather entropy from the new cpu_clock() interface > (relying on interrupts, preemption, daemons, and rcutorture's reader > thread's rock-bottom scheduling priority to provide useful entropy), > and also adds and EXPORT_SYMBOL_GPL() to make that interface available > to GPLed kernel modules such as rcutorture.
Honestly, rcutorture goes to some amazing lengths just to have this randomizing-the-delays-that-read/write-test-threads-spend-inside-or- outside-the-critical-sections thing :-) Especially, seeing that synchro-test, the other "comparable" module, just doesn't bother with all this at all. (especially check out its load == interval == do_sched == 0 case! :-)
So IMHO, considering that rcutorture isn't a "serious" user of randomness in the first place (of even a "fast-and-loose version" for that matter), you could consider a solution where you gather all the randomness you need at module_init time itself and save it somewhere, and then use it wherever you're calling into rcu_random()->cpu_clock() [ or get_random_bytes() ] in the current code. You could even make some trivial updates to those random numbers after every RCU_RANDOM_REFRESH uses, like present.
Agreed, anybody running rcutorture isn't really looking for performance, but why call get_random_bytes() or cpu_clock() (and the smp_processor_id() + irq_save/restore + export_symbol() that goes with it) when it isn't _really_ "required" as such ...
Just a suggestion,
Satyam - 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/
| |