Date: Tue, 24 Feb 2015 03:57:22 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: arch@FreeBSD.org Subject: Re: locks and kernel randomness... Message-ID: <20150224015721.GT74514@kib.kiev.ua> In-Reply-To: <20150224012026.GY46794@funkthat.com> References: <20150224012026.GY46794@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote: > I'm working on simplifying kernel randomness interfaces. I would like > to get read of all weak random generators, and this means replacing > read_random and random(9) w/ effectively arc4rand(9) (to be replaced > by ChaCha or Keccak in the future). > > The issue is that random(9) is called from any number of contexts, such > as the scheduler. This makes locking a bit more interesting. Currently, > both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect > their state. This obviously isn't compatible w/ the scheduler, and > possibly other calling contexts. > > I have a patch[1] that unifies the random interface. It converts a few > of the locks from mtx default to mtx spin to deal w/ this. This is definitely an overkill. The rebalancing minor use of randomness absolutely does not require cryptographical-strenght randomness to select a moment to rebalance thread queue. Imposing the spin lock on the whole random machinery just to allow the same random gathering code to be used for balance_ticks is detriment to the system responsivness. Scheduler is fine even with congruential generators, as you could see in the cpu_search(), look for the '69069'. Please do not enforce yet another spinlock for the system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150224015721.GT74514>