From: "Theodore Ts'o" <tytso@mit.edu>
To: "Jörn Engel" <joern@logfs.org>
Cc: John Stultz <john.stultz@linaro.org>,
Stephan Mueller <smueller@chronox.de>,
LKML <linux-kernel@vger.kernel.org>,
dave.taht@bufferbloat.net,
Frederic Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] /dev/random: Insufficient of entropy on many architectures
Date: Thu, 12 Sep 2013 19:31:55 -0400 [thread overview]
Message-ID: <20130912233155.GB5279@thunk.org> (raw)
In-Reply-To: <20130912210717.GC3809@logfs.org>
On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
>
> I happen to have a real-world system with >100k interrupts per second
> and - surprise - add_interrupt_randomness() showed up prominently in
> the profiles. I was also told twice to just remove that call. I
> resisted both times and have done far more work to reduce overhead
> while still collecting entropy. Some others would have caved in.
Would it be possible for you to send me the perf numbers that you saw?
What platform is this? x86? Some embedded processor?
> One option is to add the "input_pool.entropy_count > trickle_thresh"
> condition that all other entropy sources currently have. But instead
> I would rather rename fast_mix() to not_too_fast_mix() and implement a
> real fast_mix(). Essentially just xor the collected numbers into a
> pool and schedule something to shuffle the bits at a later point.
We can try some different things to make fast_mix() faster, but it
would be good to get some hard numbers before we start deciding we
need to do something more complicated.
One thing that comes to mind is that fast_mix() is only called in
exactly one place, and we always pass in a long. So there are
certainly ways that we could optimize fast_mix even keeping the
current mixing algorithm.
Cheers,
- Ted
next prev parent reply other threads:[~2013-09-12 23:32 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 11:31 [PATCH] /dev/random: Insufficient of entropy on many architectures Stephan Mueller
2013-09-10 11:46 ` Geert Uytterhoeven
2013-09-10 15:04 ` Theodore Ts'o
2013-09-10 16:54 ` Stephan Mueller
2013-09-10 18:25 ` Theodore Ts'o
2013-09-10 19:15 ` Stephan Mueller
2013-10-10 6:50 ` Pavel Machek
2013-10-14 21:13 ` Theodore Ts'o
2013-09-10 20:48 ` Geert Uytterhoeven
2013-09-10 21:14 ` Theodore Ts'o
2013-09-11 6:49 ` Stephan Mueller
2013-09-12 11:59 ` Geert Uytterhoeven
2013-09-12 12:08 ` Stephan Mueller
2013-09-12 12:15 ` Geert Uytterhoeven
2013-09-12 12:35 ` Stephan Mueller
2013-09-12 12:47 ` Geert Uytterhoeven
2013-09-12 12:57 ` Stephan Mueller
2013-09-12 21:18 ` Jörn Engel
2013-09-13 11:33 ` Thorsten Glaser
2013-09-12 14:25 ` Theodore Ts'o
2013-09-10 19:38 ` John Stultz
2013-09-10 19:44 ` John Stultz
2013-09-10 19:47 ` Stephan Mueller
2013-09-10 20:35 ` John Stultz
2013-09-10 20:38 ` Theodore Ts'o
2013-09-10 20:46 ` John Stultz
2013-09-10 21:10 ` Theodore Ts'o
2013-09-10 22:08 ` John Stultz
2013-09-10 22:33 ` Theodore Ts'o
2013-09-11 0:31 ` John Stultz
2013-09-11 0:50 ` Theodore Ts'o
2013-09-11 1:14 ` John Stultz
2013-09-12 20:46 ` H. Peter Anvin
2013-09-12 21:07 ` Jörn Engel
2013-09-12 23:31 ` Theodore Ts'o [this message]
2013-09-12 23:35 ` Jörn Engel
2013-09-13 0:00 ` Jörn Engel
2013-09-16 15:40 ` [PATCH,RFC] random: make fast_mix() honor its name Jörn Engel
2013-09-21 21:25 ` Theodore Ts'o
2013-09-21 21:41 ` Theodore Ts'o
2013-09-22 3:05 ` Theodore Ts'o
2013-09-22 21:01 ` Jörg-Volker Peetz
2013-09-22 21:27 ` Theodore Ts'o
2013-09-22 20:53 ` Jörn Engel
2013-09-22 23:36 ` Theodore Ts'o
2013-09-23 0:16 ` Jörn Engel
2013-09-23 2:43 ` Theodore Ts'o
2013-09-23 15:02 ` Jörn Engel
2013-09-23 7:39 ` Jörg-Volker Peetz
2013-09-22 20:31 ` Jörn Engel
2013-09-22 20:14 ` Jörn Engel
2013-09-12 21:31 ` [PATCH] /dev/random: Insufficient of entropy on many architectures Jörn Engel
2013-09-13 5:36 ` Stephan Mueller
2013-09-13 11:54 ` Thorsten Glaser
2013-09-13 19:29 ` Theodore Ts'o
2013-09-13 15:26 ` Jörn Engel
2013-09-13 18:59 ` Theodore Ts'o
2013-09-15 11:12 ` Stephan Mueller
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=20130912233155.GB5279@thunk.org \
--to=tytso@mit.edu \
--cc=dave.taht@bufferbloat.net \
--cc=fweisbec@gmail.com \
--cc=joern@logfs.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=tglx@linutronix.de \
/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.