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
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
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
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
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
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
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
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
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
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
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?
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
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
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
14 matches
Mail list logo