All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: tytso@mit.edu, linux-kernel@vger.kernel.org,
	kirill.shutemov@linux.intel.com, herbert@gondor.apana.org.au,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/3] Make /dev/urandom scalable
Date: Thu, 24 Sep 2015 07:37:39 -0400	[thread overview]
Message-ID: <5603E083.8020004@gmail.com> (raw)
In-Reply-To: <20150923232841.GK1747@two.firstfloor.org>

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On 2015-09-23 19:28, Andi Kleen wrote:
>> 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.
Using /dev/urandom directly, yes that doesn't make sense because it 
consistent returns non-uniformly random numbers when used to generate 
larger amounts of entropy than the blocking pool can source, but most 
that use their own PRNG's seed them off of /dev/urandom, and there are 
cases I've seen of people doing very large numbers (on the order of 
millions) of short (15 or so minutes run time on decent hardware) 
simulations that do this.

As for a run-time tunable, I agree that that would be better than 
build-time, and I also agree that it should be done later.  The only 
reason I suggested a build time tunable was that I figured it would be a 
lot easier to do than run-time.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-09-24 11:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 23:16 [PATCH 1/3] Make /dev/urandom scalable Andi Kleen
2015-09-22 23:16 ` [PATCH 2/3] random: Make input to output pool balancing per cpu Andi Kleen
2015-09-22 23:16 ` [PATCH 3/3] random: Add pool name to urandom_read trace point Andi Kleen
2015-09-22 23:25 ` [PATCH 1/3] Make /dev/urandom scalable Andi Kleen
2015-09-23 10:32 ` Rasmus Villemoes
2015-09-23 21:54   ` Andi Kleen
2015-09-23 19:40 ` Austin S Hemmelgarn
2015-09-23 23:28   ` Andi Kleen
2015-09-24 11:37     ` Austin S Hemmelgarn [this message]
2015-09-24 13:12       ` Theodore Ts'o
2015-09-24 16:00         ` Austin S Hemmelgarn
2015-09-24 16:52           ` Jeff Epler
2015-09-24 19:11             ` Austin S Hemmelgarn
2015-09-24 20:00               ` Jeff Epler
2015-09-24 20:14               ` Theodore Ts'o
2015-09-25 11:41                 ` Austin S Hemmelgarn
2015-09-25 19:07                   ` Austin S Hemmelgarn
2015-09-25 20:24                     ` Theodore Ts'o
2015-09-29 12:06                       ` Austin S Hemmelgarn
2015-09-29 11:57                     ` Austin S Hemmelgarn
2015-09-23 21:10 ` Theodore Ts'o
2015-09-23 21:25   ` Andi Kleen
2015-09-24 17:19 Updated scalable urandom patchkit Andi Kleen
2015-09-24 17:19 ` [PATCH 1/3] Make /dev/urandom scalable Andi Kleen
2015-09-30 14:40   ` Rasmus Villemoes
2015-10-06 22:05 Andi Kleen
2016-02-10 23:01 Scalable random patchkit revisited Andi Kleen
2016-02-10 23:01 ` [PATCH 1/3] Make /dev/urandom scalable Andi Kleen
2016-03-01  5:17 Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5603E083.8020004@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.