From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 14:58:22 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953FFCC0 for ; Tue, 24 Feb 2015 14:58:22 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64A545E3 for ; Tue, 24 Feb 2015 14:58:22 +0000 (UTC) Received: by pdbfl12 with SMTP id fl12so33883099pdb.4 for ; Tue, 24 Feb 2015 06:58:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Kn8s07214KOR7UmcUTt1A6DN3YqzmFc4csgwx7+x3aM=; b=V1GJaLqEuWQRqO66q1G7km1EAMoLlF9ymkBLT1mCl66ND2qPMF1jIdJ2NGXulUh7rH hBhp7W24WEJQ0DKxRdCfDeSONMwfIt0WPcDHftGyjJ6vrClMVXWcaPa8neYwqmd/Gabb hp6O5b20npEDt4A4gOBmihNOBKPQbOsORU/ZVHPTfOJuHrJXGJBplwViV9QZBJbBUkPV ZzCNi9iX5AipptW+3/+fX1zGehDsOUarmd4OR90YBLmJZltvVq7ydDOs1VEenLmPgTTv mrm9eKIfq7Ipmhi800SfPxA23O+5+qoAKaR7i5mcL/JmiSvZVU8shs19A7U6KHrHmOxe G8Hw== X-Gm-Message-State: ALoCoQnvWh3m9V5yCKZLJXnXRN3BQHcFljDzt34KLKhEP6AePaQP6HBPlzisu37iJJHs1KFZLilr X-Received: by 10.68.69.108 with SMTP id d12mr4262793pbu.137.1424789901699; Tue, 24 Feb 2015 06:58:21 -0800 (PST) Received: from macintosh-3c0754232d17.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id jw8sm38372088pbc.73.2015.02.24.06.58.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 06:58:21 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: locks and kernel randomness... From: Warner Losh In-Reply-To: <54EBFFDC.4090905@astrodoggroup.com> Date: Tue, 24 Feb 2015 07:58:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150224012026.GY46794@funkthat.com> <20150224015721.GT74514@kib.kiev.ua> <54EBDC1C.3060007@astrodoggroup.com> <20150224024250.GV74514@kib.kiev.ua> <54EBFFDC.4090905@astrodoggroup.com> To: Harrison Grundy X-Mailer: Apple Mail (2.2070.6) Cc: Konstantin Belousov , freebsd-arch@freebsd.org 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 14:58:22 -0000 > On Feb 23, 2015, at 9:36 PM, Harrison Grundy = wrote: >=20 >=20 >=20 > On 02/23/15 18:42, Konstantin Belousov wrote: >> On Mon, Feb 23, 2015 at 06:04:12PM -0800, Harrison Grundy wrote: >>>=20 >>>=20 >>> 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). >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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'. >>>>=20 >>>> Please do not enforce yet another spinlock for the system.=20 >>>> _______________________________________________ >>>=20 >>> The patch attached to >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197922 switches >>> sched_balance to use get_cyclecount, which is also a suitable source >>> of entropy for this purpose. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >=20 > 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=E2=80=99t exist on older ARM hardware. Some SoCs have something similar to a real-time clock that you can read, but that=E2=80=99= 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. >=20 > New patch attached to the PR that simply removes the randomness = entirely. Are you sure about that? Warner