From owner-svn-src-all@freebsd.org Thu Jul 16 22:28:37 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEDA29A44DB; Thu, 16 Jul 2015 22:28:37 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (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 8E233198F; Thu, 16 Jul 2015 22:28:37 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pdbbh15 with SMTP id bh15so5556436pdb.1; Thu, 16 Jul 2015 15:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SbGqTW2/cl6V1nZiB48sY1P6NLQo+XMznhVQo41e8rk=; b=0vvffM5kQ6na6TsGrChQAnmxEZE9mLHUzxfXqLKGCiyvLcxxbGMZK1ea+xngtCihyo nEJ+HeCZrmiVs0NyklL8PeyrlGQtu9U6bqstfF2wYYxhXqIvKkVQ9BVnwrENM0Unk8vp l4WA1uTn+OMODl/+DnRunYZPtekhSSTS59jgRlbHHgBNHNHHA+g0STVLB7b5qoH0rv37 17qZ1wCK0LUsVuACeuFtE+eJIXQAyi+gLANCJvP6SJHLLWWaUlPLYKzsXSmHidbxAD8z JZFvKawYZnIYQ1MUAeFdIngvmv3GS8HSJ+pJ6q3ylpimx7jHEr0lMzmT0vqJhUEAa6aq TkkA== MIME-Version: 1.0 X-Received: by 10.69.17.130 with SMTP id ge2mr22625173pbd.75.1437085717022; Thu, 16 Jul 2015 15:28:37 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Thu, 16 Jul 2015 15:28:36 -0700 (PDT) In-Reply-To: <87D9CCA8-B77F-4CBD-85EC-08C4A9D8413E@FreeBSD.org> References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <6FF99E82-AE79-4112-8EB9-DC35B75F498D@FreeBSD.org> <1437055729.1334.359.camel@freebsd.org> <87D9CCA8-B77F-4CBD-85EC-08C4A9D8413E@FreeBSD.org> Date: Thu, 16 Jul 2015 15:28:36 -0700 X-Google-Sender-Auth: ttcVEe7kzsgrlqtxnY2KzyKZ6J8 Message-ID: Subject: Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy... From: "K. Macy" To: Mark R V Murray Cc: Ian Lepore , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 22:28:37 -0000 I discovered this when I MFC'd and my kernel wouldn't link because of unresolved symbols. I thought I had put the issue aside when I added RANDOM_DUMMY to my kernel config. However, I just hit this: while (!random_alg_context.ra_seeded()) { if (nonblock) { error =3D EWOULDBLOCK; break; } tsleep(&random_alg_context, 0, "randseed", hz/10); /* keep tapping away at the pre-read until we seed/unblock.= */ random_alg_context.ra_pre_read(); printf("random: %s unblock wait\n", __func__); } My system wouldn't boot because this was endlessly spamming the console. I don't know what the right default here is. But I can say that this is not it. I would also like to observe that a good back of the envelope per-packet budget is 1000 cycles (stock FreeBSD is much worse than this - nonetheless it is a reasonable figure to strive for). Many drivers will for a variety of reasons allocate mbufs and clusters separately. This means that if you're harvesting on alloc / free, your function is being called 4 times per-packet. Let's have a hypothetical that your function takes 50 cycles* - in this case your entropy collection would be consuming a full 20% of the per-packet budget. At high-packet rates your entropy is likely to be caused more by indeterminacy of cache misses and lock contention than any true randomness in the arrival rate. * It may be less, it may be much more. I'm not sure where the workflow fell short in this instance, but I'm inclined to believe that this could have been handled better. -K On Thu, Jul 16, 2015 at 11:29 AM, Mark R V Murray wrote= : > >> On 16 Jul 2015, at 15:08, Ian Lepore wrote: >> >> On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote: >>>> On 15 Jul 2015, at 23:43, Adrian Chadd wrote: >>>> >>>>> - Add harvesting of slab allocator events. This needs to be checked f= or >>>>> weighing down the allocator code. >>>> >>>> Hi, >>>> >>>> Is this really doing it upon every one of those events? eg, for each >>>> mbuf alloc through UMA? >>> >>> Only if you turn it on! >>> >>> M >>> >> >> In random_harvestq_init() I see >> >> harvest_context.hc_source_mask =3D RANDOM_HARVEST_EVERYTHING_MASK; >> >> and >> >> #define RANDOM_HARVEST_EVERYTHING_MASK ((1 << (RANDOM_ENVIRONMENTAL_END >> + 1)) - 1) >> >> So doesn't that include the RANDOM_FAST flag that controls harvesting >> during every UMA alloc and free call? And that harvesting appears to be >> anything but fast, at least at a glance... it looks like it passes the >> entire struct uma_zone to the jenkins hash function... is there really >> useful entropy in all the data in that struct? > > Well spotted, but fear not. All sources are on at startup, and this > is to ensure that the generator has maximal access to entropy while > booting. > > One of the default duties of etc/rc.d/random is to turn off the UMA > and ATIME sources. These may be turned on if you want them, but by > default on the fully booted system they are off. > > See =E2=80=98sysctl kern.random.harvest.mask_symbolic=E2=80=99 and note t= hat the > disabled sources are in []. > > I have yet to do a full set of benchmarks, but I have discussed > this with RWatson. A silly benchmark (make world) shows little > effect, but I will be doing this properly in coming months. > > In answer to you final question - yes. The UMA entropy is a bit > spread out, but it is good. > > M > -- > Mark R V Murray > > _______________________________________________ > svn-src-head@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org"