All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Andi Kleen <andi@firstfloor.org>,
	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: Wed, 23 Sep 2015 23:54:47 +0200	[thread overview]
Message-ID: <20150923215447.GJ1747@two.firstfloor.org> (raw)
In-Reply-To: <87r3lpo27e.fsf@rasmusvillemoes.dk>

> > +{
> > +	struct entropy_store *pool = &nonblocking_pool;
> > +
> > +	/*
> > +	 * Non node 0 pools may take longer to initialize. Keep using
> > +	 * the boot nonblocking pool while this happens.
> > +	 */
> > +	if (nonblocking_node_pool)
> > +		pool = nonblocking_node_pool[numa_node_id()];
> > +	if (!pool->initialized)
> > +		pool = &nonblocking_pool;
> > +	return pool;
> > +}
> 
> I assume this can't get called concurrently with rand_initialize
> (otherwise pool may be NULL even if nonblocking_node_pool is non-NULL). 

Yes. I can move the assignment to the global last and add a memory
barrier.

> > +	char name[40];
> > +
> > +	nonblocking_node_pool = kzalloc(num_nodes * sizeof(void *),
> > +					GFP_KERNEL|__GFP_NOFAIL);
> > +
> 
> Why kzalloc, when you immediately initialize all elements? New uses of
> __GFP_NOFAIL seem to be frowned upon. How hard would it be to just fall
> back to only using the single statically allocated pool?

It's already doing that.

> 
> Does rand_initialize get called before or after other initialization
> code updates node_possible_map to reflect the actual possible number of
> nodes? If before, won't we be wasting a lot of memory (not to mention
> that we then might as well allocate all the nonblocking pools statically
> based on MAX_NUMNODES).

I'll check.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2015-09-23 21:54 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 [this message]
2015-09-23 19:40 ` Austin S Hemmelgarn
2015-09-23 23:28   ` Andi Kleen
2015-09-24 11:37     ` Austin S Hemmelgarn
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
  -- strict thread matches above, loose matches on Subject: below --
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=20150923215447.GJ1747@two.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=ak@linux.intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --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.