From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932428AbbJMVKx (ORCPT ); Tue, 13 Oct 2015 17:10:53 -0400 Received: from ns.horizon.com ([71.41.210.147]:47575 "HELO ns.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932143AbbJMVKd (ORCPT ); Tue, 13 Oct 2015 17:10:33 -0400 Date: 13 Oct 2015 17:10:30 -0400 Message-ID: <20151013211030.30325.qmail@ns.horizon.com> From: "George Spelvin" To: ahferroin7@gmail.com, andi@firstfloor.org, jepler@unpythonic.net, linux-kernel@vger.kernel.org, linux@horizon.com, linux@rasmusvillemoes.dk, tytso@mit.edu Subject: Re: Updated scalable urandom patchkit In-Reply-To: <20151013162044.GD3533@two.firstfloor.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Ted's patch peaks at 350K with four CPUs, but then quickly degrades to > 50K ops/s at 20+ CPUs. At 144 CPUs it is slightly faster again at ~80K. Good to know, thanks! With its race conditions, it's basically a "best case" for that particular design, which tells me that more significant changes are required. Off hand, do you know how large a read each operation is? I want to reduce mixback from once per 10 bytes to once per read, and the size ratio will give me some idea of how large an improvement to expect. > Spelvin's patch peaks at only 140K at 2 CPUs (so it's slower than base line), > stays around 120K upto 20, then degrades quickly to 50K and then slowly > improves again to ~80K. Sorry to make you go to the trouble; I knew from discussions with Ted that it wasn't going to work. It was mostly just in the form of a patch for the sake of a more concrete discussion. I'll have a patch that I hope will do some good for testing in a couple of hours. > The duplicated pool patch is ~200K upto 20 CPus, 400K upto 40, 600K at > slightly below 60 CPUs, and then very slowly degrades to 520K at 144. Shitty performance is practically a design goal of /dev/urandom. You are NOT supposed to hit it more than once per minute per thread. But since we have a real-world problem with it, Ted's "abusse mitigation mode" idea (where the kernel does what the app should do: seed a private CPRNG and use that) will provide good security at extremely high access rates.