Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1389410

Re: random(4) changes

From Stephan Mueller <smueller@chronox.de>
Newsgroups linux.kernel
Subject Re: random(4) changes
Date 2016-04-27 19:50 +0200
Message-ID <rsBL3-59n-5@gated-at.bofh.it> (permalink)
References <rqRKj-Ux-41@gated-at.bofh.it> <rrSXD-1rj-3@gated-at.bofh.it> <rrUwr-2Mp-43@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:

Hi Andi,

> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > > 
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> > 
> > That would imply that even when you have a system with 1000 CPUs, you want
> > to have a large amount of random numbers. Is this the use case?
> 
> That is right. Large systems do more work than small systems.
> If the system is for example handling SSL connections it needs
> more random numbers to handle more connections.

I have ported the NUMA logic to the LRNG. It instantiates the secondary DRBG 
once for each NUMA node just like your patch.

Though, the initialization of the instances of the secondary DRBGs is 
different. I serialize the initialization such that one DRBG instance is 
seeded at a time from the primary DRBG.

I tested the code by using the per-CPU logic instead of per-NUMA node. This 
test shows that all works fine.

I then changed it to use a per NUMA node instance. It works on my test systems 
which instantiate the DRBG only once as I only have one node.

May I ask you to test that code on your system as I do not have access to a 
NUMA system? I will release a new version shortly.

Ciao
Stephan

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

random(4) changes Sandy Harris <sandyinchina@gmail.com> - 2016-04-23 00:30 +0200
  Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-23 10:00 +0200
  Re: random(4) changes Theodore Ts'o <tytso@mit.edu> - 2016-04-24 04:10 +0200
    Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-24 10:10 +0200
      Re: random(4) changes Theodore Ts'o <tytso@mit.edu> - 2016-04-26 05:10 +0200
        Re: random(4) changes Herbert Xu <herbert@gondor.apana.org.au> - 2016-04-26 13:10 +0200
          Re: random(4) changes Andi Kleen <andi@firstfloor.org> - 2016-04-26 22:50 +0200
            Re: random(4) changes Herbert Xu <herbert@gondor.apana.org.au> - 2016-04-27 06:30 +0200
        Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-26 20:30 +0200
        Re: random(4) changes Pavel Machek <pavel@ucw.cz> - 2016-04-26 20:50 +0200
          Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-26 21:00 +0200
            Re: random(4) changes Pavel Machek <pavel@ucw.cz> - 2016-04-26 21:50 +0200
  Re: random(4) changes Andi Kleen <andi@firstfloor.org> - 2016-04-25 18:10 +0200
    Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-25 19:30 +0200
      Re: random(4) changes Andi Kleen <andi@firstfloor.org> - 2016-04-25 19:40 +0200
        Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-25 20:00 +0200
          Re: random(4) changes Andi Kleen <andi@firstfloor.org> - 2016-04-25 21:40 +0200
            Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-26 14:10 +0200
            Re: random(4) changes Stephan Mueller <smueller@chronox.de> - 2016-04-27 19:50 +0200
    Re: random(4) changes Theodore Ts'o <tytso@mit.edu> - 2016-04-26 03:10 +0200
    Re: random(4) changes Sandy Harris <sandyinchina@gmail.com> - 2016-04-26 14:50 +0200

csiph-web