[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wihkv1EtqcKcMS2kUQB86WRykQhknOnH08OcBH0Cz3Jtg@mail.gmail.com>
Date: Mon, 10 Aug 2020 09:31:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Willy Tarreau <w@....eu>
Cc: George Spelvin <lkml@....org>, Netdev <netdev@...r.kernel.org>,
Amit Klein <aksecurity@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Andrew Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
"Theodore Ts'o" <tytso@....edu>,
Marc Plumb <lkml.mplumb@...il.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Florian Westphal <fw@...len.de>
Subject: Re: [DRAFT PATCH] random32: make prandom_u32() output unpredictable
On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau <w@....eu> wrote:
>
> Doing testing on real hardware showed that retrieving the TSC on every
> call had a non negligible cost, causing a loss of 2.5% on the accept()
> rate and 4% on packet rate when using iptables -m statistics.
And by "real hardware" I assume you mean x86, with a fairly fast and
high-performance TSC for get_random_entropy().
Reading the TSC takes on the order of 20-50 cycles, iirc.
But it can actually be *much* more expensive. On non-x86, it can be an
IO cycle to external chips.
And on older hardware VM's in x86, it can be a vm exit etc, so
thousands of cycles. I hope nobody uses those VM's any more, but it
would be a reasonable test-case for some non-x86 implementations, so..
IOW, no. You guys are - once again - ignoring reality.
Linus
Powered by blists - more mailing lists