From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756208AbbIWX2p (ORCPT ); Wed, 23 Sep 2015 19:28:45 -0400 Received: from one.firstfloor.org ([193.170.194.197]:45539 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755901AbbIWX2o (ORCPT ); Wed, 23 Sep 2015 19:28:44 -0400 Date: Thu, 24 Sep 2015 01:28:42 +0200 From: Andi Kleen To: Austin S Hemmelgarn Cc: Andi Kleen , tytso@mit.edu, linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com, herbert@gondor.apana.org.au, Andi Kleen Subject: Re: [PATCH 1/3] Make /dev/urandom scalable Message-ID: <20150923232841.GK1747@two.firstfloor.org> References: <1442963767-14945-1-git-send-email-andi@firstfloor.org> <5603004A.20801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5603004A.20801@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I'd almost say that making the partitioning level configurable at > build time might be useful. I can see possible value to being able > to at least partition down to physical cores (so, shared between > HyperThreads on Intel processors, and between Compute Module cores > on AMD processors), as that could potentially help people running > large numbers of simulations in parallel. I don't like build time size configurations. It doesn't make sense for simulations to use urandom. It may make sense to have some run time tunable, but for now that's too much complexity. So I'll stay with the simpler per node pool for now. -Andi