From: Andi Kleen <andi@firstfloor.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: Andi Kleen <andi@firstfloor.org>,
Sandy Harris <sandyinchina@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Jason Cooper <jason@lakedaemon.net>, John Denker <jsd@av8n.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: random(4) changes
Date: Mon, 25 Apr 2016 12:35:32 -0700 [thread overview]
Message-ID: <20160425193531.GC13997@two.firstfloor.org> (raw)
In-Reply-To: <7735834.PWhNOHfhKX@positron.chronox.de>
> > > 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.
BTW the problems happen long before 1000 CPUs, more like 12-18 cores
competing.
Also today's large system is tomorrow's small systems. The
systems affected are actually not that large anymore.
The original numbers
Without patchkit:
1 node: 1x
2 nodes: 0.75x
3 nodes: 0.55x
4 nodes: 0.42x
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2016-04-25 19:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 22:27 random(4) changes Sandy Harris
2016-04-23 7:52 ` Stephan Mueller
2016-04-24 2:03 ` Theodore Ts'o
2016-04-24 8:03 ` Stephan Mueller
2016-04-26 3:07 ` Theodore Ts'o
2016-04-26 11:04 ` Herbert Xu
2016-04-26 20:47 ` Andi Kleen
2016-04-27 4:23 ` Herbert Xu
2016-04-26 18:24 ` Stephan Mueller
2016-04-26 18:44 ` Pavel Machek
2016-04-26 18:55 ` Stephan Mueller
2016-04-26 19:41 ` Pavel Machek
2016-04-25 16:06 ` Andi Kleen
2016-04-25 17:25 ` Stephan Mueller
2016-04-25 17:38 ` Andi Kleen
2016-04-25 17:56 ` Stephan Mueller
2016-04-25 19:35 ` Andi Kleen [this message]
2016-04-26 12:01 ` Stephan Mueller
2016-04-27 17:47 ` Stephan Mueller
2016-04-26 1:00 ` Theodore Ts'o
2016-04-26 12:42 ` Sandy Harris
-- strict thread matches above, loose matches on Subject: below --
2016-04-26 1:59 George Spelvin
2016-04-26 18:43 ` Stephan Mueller
2016-04-26 20:43 ` George Spelvin
2016-04-26 21:01 ` Stephan Mueller
2016-04-27 0:23 ` George Spelvin
2016-04-27 18:03 ` George Spelvin
2016-04-28 20:15 ` Stephan Mueller
2016-04-29 7:29 ` George Spelvin
2016-04-29 8:02 ` Stephan Mueller
2016-04-29 9:34 ` George Spelvin
2016-04-29 9:53 ` Stephan Mueller
2016-04-29 11:04 ` George Spelvin
2016-04-29 11:18 ` Stephan Mueller
2016-04-29 18:02 ` George Spelvin
2016-04-29 18:41 ` Stephan Mueller
2016-04-29 20:08 ` George Spelvin
2016-04-29 21:54 ` Stephan Mueller
2016-04-29 22:32 ` George Spelvin
2016-04-29 0:47 ` George Spelvin
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=20160425193531.GC13997@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=jason@lakedaemon.net \
--cc=jsd@av8n.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=smueller@chronox.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).