Date: Tue, 24 Feb 2015 09:08:02 -0800 From: Harrison Grundy <harrison.grundy@astrodoggroup.com> To: freebsd-arch@freebsd.org Subject: Re: locks and kernel randomness... Message-ID: <54ECAFF2.2050903@astrodoggroup.com> In-Reply-To: <E745148E-12AF-4205-B340-B1795B44B257@bsdimp.com> References: <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua> <54EBFFDC.4090905@astrodoggroup.com> <E745148E-12AF-4205-B340-B1795B44B257@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/24/15 06:58, Warner Losh wrote: > >> On Feb 23, 2015, at 9:36 PM, Harrison Grundy >> <harrison.grundy@astrodoggroup.com> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54ECAFF2.2050903>