From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 17:08:05 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 22C817A2 for ; Tue, 24 Feb 2015 17:08:05 +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 B99FD844 for ; Tue, 24 Feb 2015 17:08:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 4C50AE3E5 for ; Tue, 24 Feb 2015 12:08:02 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.162, 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 i0qCbApSVs1G for ; Tue, 24 Feb 2015 12:08:02 -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 E4795E22B for ; Tue, 24 Feb 2015 12:08:01 -0500 (EST) Message-ID: <54ECAFF2.2050903@astrodoggroup.com> Date: Tue, 24 Feb 2015 09:08:02 -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> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua> <54EBFFDC.4090905@astrodoggroup.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 17:08:05 -0000 On 02/24/15 06:58, Warner Losh wrote: > >> On Feb 23, 2015, at 9:36 PM, Harrison Grundy >> wrote: >> >> >> >> On 02/23/15 18:42, Konstantin Belousov wrote: >>> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy >>> wrote: >>>> >>>> >>>> On 02/23/15 17:57, Konstantin Belousov wrote: >>>>> 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. >>>>> _______________________________________________ >>>> >>>> The patch attached to >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197922 >>>> switches sched_balance to use get_cyclecount, which is also a >>>> suitable source of entropy for this purpose. >>>> >>>> It would also be possible to make the scheduler deterministic >>>> here, using cpuid or some such thing to make sure all CPUs >>>> don't fire the balancer at the same time. >>>> >>> >>> The patch in the PR is probably in the right direction, but >>> might be too simple, unless somebody dispel my fallacy. I >>> remember seeing claims that on the very low-end embedded >>> devices the get_cyclecount() method may be non-functional, i.e. >>> returning some constant, probably 0. I somehow associate MIPS >>> arch with this bias. >>> >> >> Talking to some of the arm and MIPS developers, it appears >> get_cyclecount() may be slow on some older ARM hardware... (In >> particular, hardware that doesn't support SMP anyway.) > > It simply doesn’t exist on older ARM hardware. Some SoCs have > something similar to a real-time clock that you can read, but > that’s not reliable for this use. > >> However, after a quick test on some machines here, I don't think >> this function actually needs randomness, due to the large number >> of other pathways ULE uses to balance load. >> >> New patch attached to the PR that simply removes the randomness >> entirely. > > Are you sure about that? I'm testing on an 8 core AMD Bulldozer machine without any noticable issues. You could game the scheduler a bit by running near the "beginning" of the balance interval, but the preemption, idle steal, and priority recalculation-caused migrations pretty much wipe out the effect. That being said, get_cyclecount is pretty cheap, and this code doesn't run *that* often, so if there's a rare edge case I'm not running into that benefits from it, I suspect it's worth keeping the... 'faux' randomness in there somewhere. Anyone else want to test it? --- Harrison > > Warner > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch To > unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" >