[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2+t1Wy1vgz-ie4h=Epsdy2hrM2ycmEsFptwNqwJ57CCQ@mail.gmail.com>
Date: Fri, 21 Jul 2017 17:09:11 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Stephan Müller <smueller@...onox.de>
Cc: "Theodore Ts'o" <tytso@....edu>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Jason A. Donenfeld" <jason@...c4.com>,
linux-crypto@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v12 3/4] Linux Random Number Generator
On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller <smueller@...onox.de> wrote:
> Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o:
>> Um, the timer is the largest number of interrupts on my system. Compare:
>>
>> CPU0 CPU1 CPU2 CPU3
>> LOC: 6396552 6038865 6558646 6057102 Local timer interrupts
>>
>> with the number of disk related interrupts:
>>
>> 120: 21492 139284 40513 1705886 PCI-MSI 376832-edge
>> ahci[0000:00:17.0]
>
> They seem to be not picked up with the add_interrupt_randomness function.
On x86, the local APIC timer has some special handling in
arch/x86/entry/entry_64.S that does not go through handle_irq_event().
I would assume that this is different when you boot with the "noapictimer"
option and use the hpet clockevent instead.
On other architectures, the timer interrupt is often handled as a regular
IRQ as well.
Arnd
Powered by blists - more mailing lists