Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-23 Thread Jörn Engel
On Sun, 22 September 2013 22:43:38 -0400, Theodore Ts'o wrote: > On Sun, Sep 22, 2013 at 08:16:23PM -0400, Jörn Engel wrote: > > How about we switch between the two mixing functions depending on the > > interrupt load? If this CPU has seen fewer than 1000 interrupts in > > the last second, use the

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-23 Thread Jörg-Volker Peetz
Thanks for your patience and elaborated answer. Theodore Ts'o wrote, on 09/22/2013 23:27: > On Sun, Sep 22, 2013 at 11:01:42PM +0200, Jörg-Volker Peetz wrote: >> just out of interest I would like to ask why this mixing function has to be >> that >> complicated. For example, even if the input is a

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Theodore Ts'o
On Sun, Sep 22, 2013 at 08:16:23PM -0400, Jörn Engel wrote: > How about we switch between the two mixing functions depending on the > interrupt load? If this CPU has seen fewer than 1000 interrupts in > the last second, use the better one, otherwise us the cheaper one? I guess the question here i

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörn Engel
On Sun, 22 September 2013 19:36:41 -0400, Theodore Ts'o wrote: > On Sun, Sep 22, 2013 at 04:53:34PM -0400, Jörn Engel wrote: > > > > And I want to keep that function. Essentially the point of fast_mix() > > is to ratelimit _mix_pool_bytes(). Naïve ratelimiting would simply > > discard the input

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Theodore Ts'o
On Sun, Sep 22, 2013 at 04:53:34PM -0400, Jörn Engel wrote: > > And I want to keep that function. Essentially the point of fast_mix() > is to ratelimit _mix_pool_bytes(). Naïve ratelimiting would simply > discard the input once the ratelimit has been reached. My proposal is > to still use the i

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörn Engel
On Sun, 22 September 2013 17:27:52 -0400, Theodore Ts'o wrote: > > The structure of the mixing functions in /dev/random has been well > studied, and validatetd in a number of different academic papers. So > I prefer to stick with the basic architecture, even as it is scaled > down for speed reaso

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörn Engel
On Sat, 21 September 2013 17:41:18 -0400, Theodore Ts'o wrote: > > BTW, just to give another example of the difference between the mixing > funtions, try compiling the following with and without ORIG_MIX defined... Garbage in, garbage out again. If there is absolutely no randomness in the input

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörn Engel
On Sat, 21 September 2013 17:25:10 -0400, Theodore Ts'o wrote: > On Mon, Sep 16, 2013 at 11:40:27AM -0400, Jörn Engel wrote: > > > > Here is a patch to make add_interrupt_randomness() significantly > > cheaper without significantly impacting the quality. The second part > > is my personal opinion

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Theodore Ts'o
On Sun, Sep 22, 2013 at 11:01:42PM +0200, Jörg-Volker Peetz wrote: > just out of interest I would like to ask why this mixing function has to be > that > complicated. For example, even if the input is always 0 and the pool is seeded > with pool[0] = 1 (as in your test program) this algorithm gener

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörg-Volker Peetz
Hi Theodore, Theodore Ts'o wrote, on 09/22/2013 05:05: > The following fast_mix function, with the loop unrolling, is about 70% > slower than your proposed version, but it's still four times faster > than the original byte-based fast_mix function. This is what I'm > considering using as a comprom

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-21 Thread Theodore Ts'o
The following fast_mix function, with the loop unrolling, is about 70% slower than your proposed version, but it's still four times faster than the original byte-based fast_mix function. This is what I'm considering using as a compromise. Any comments or objections?

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-21 Thread Theodore Ts'o
BTW, just to give another example of the difference between the mixing funtions, try compiling the following with and without ORIG_MIX defined... - Ted #include #include #include #include /* #define ORIG_MIX */ #define ADD_ROTATE #define DEBUG_P

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-21 Thread Theodore Ts'o
On Mon, Sep 16, 2013 at 11:40:27AM -0400, Jörn Engel wrote: > > Here is a patch to make add_interrupt_randomness() significantly > cheaper without significantly impacting the quality. The second part > is my personal opinion and others might disagree. > > So far this has only seen userspace perf

[PATCH,RFC] random: make fast_mix() honor its name

2013-09-16 Thread Jörn Engel
On Thu, 12 September 2013 19:31:55 -0400, Theodore Ts'o wrote: > 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 w