Skip site navigation (1)Skip section navigation (2)
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>