From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 02:21:39 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34393B0D for ; Tue, 24 Feb 2015 02:21:39 +0000 (UTC) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C56A179F for ; Tue, 24 Feb 2015 02:21:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 4AF59E48B for ; Mon, 23 Feb 2015 21:21:37 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.164, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692] Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjJg-4Djubv4 for ; Mon, 23 Feb 2015 21:21:37 -0500 (EST) Received: from bsddt1241.lv01.astrodoggroup.com (unknown [40.141.24.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id E948BE495 for ; Mon, 23 Feb 2015 21:21:36 -0500 (EST) Message-ID: <54EBE02F.5070705@astrodoggroup.com> Date: Mon, 23 Feb 2015 18:21:35 -0800 From: Harrison Grundy User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: locks and kernel randomness... References: <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <20150224020902.GZ46794@funkthat.com> In-Reply-To: <20150224020902.GZ46794@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 02:21:39 -0000 On 02/23/15 18:09, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Tue, Feb 24, 2015 at > 03:57 +0200: >> 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'. > > Then why doesn't it use this then? This is exactly why I don't > want random to be a congruential generator... If you're so sure > that you don't need cryptographic secure and that it's a > performance benefit to do so, then you're free to roll your own, > but almost all of the time, code won't meet both requirements. > > I haven't audited all the places where random is currently being > called that might require not sleeping. The scheduler happens to > be the first one I ran into... > >> Please do not enforce yet another spinlock for the system. > > I sent this email asking for help for how to avoid a spin lock. > I'd appreciate if you could suggest how to improve my patch. > > Thanks. > It seems to me that "random()" *should* return truly cryptographic randomness, while some other cheap mechanism (say randomish() or notrandom()), that explicitly isn't of cryptographic quality should be used for cases where "Sort of random" is good enough. This way, developers can actually decide which one they're going to use and where it's worth the performance cost to get real randomness. The scheduler doesn't happen to meet the latter case, so it's probably not a great example case and should be treated differently. --- Harrison