[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4a30d2e-b7eb-0f2e-933d-97f5bb006428@canonical.com>
Date: Wed, 22 Jan 2020 10:27:18 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...onical.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-rtc@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/8] rtc: cmos: Use shared IRQ only for Microsoft
Surface 3
On 17/01/2020 14:56, Andy Shevchenko wrote:
> As reported by Guilherme:
>
> The rtc-cmos interrupt setting was changed in the commit 079062b28fb4
> ("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order
> to allow shared interrupts; according to that commit's description,
> some machine got kernel warnings due to the interrupt line being shared
> between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing
> that time.
>
> After the aforementioned commit though it was observed a huge increase
> in lost HPET interrupts in some systems, observed through the following
> kernel message:
>
> [...] hpet1: lost 35 rtc interrupts
>
> After investigation, it was narrowed down to the shared interrupts
> usage when having the kernel option "irqpoll" enabled. In this case,
> all IRQ handlers are called for non-timer interrupts, if such handlers
> are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to
> hpet_rtc_interrupt(), which will produce the kernel "lost interrupts"
> message after doing work - lots of readl/writel to HPET registers, which
> are known to be slow.
>
> This patch changes this behavior by preventing shared interrupts for
> everything, but Microsoft Surface 3 as stated in the culprit commit message.
> Although "irqpoll" is not a default kernel option, it's used in some contexts,
> one being the kdump kernel (which is an already "impaired" kernel usually
> running with 1 CPU available), so the performance burden could be considerable.
> Also, the same issue would happen (in a shorter extent though) when using
> "irqfixup" kernel option.
>
> In a quick experiment, a virtual machine with uptime of 2 minutes produced
>> 300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without
> sharing interrupts this number reduced to 1 interrupt. Machines with more
> hardware than a VM should generate even more unnecessary HPET interrupts
> in this scenario.
>
> Fixes: 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
> Reported-by: Guilherme G. Piccoli <gpiccoli@...onical.com>
> Suggested-by: Thomas Gleixner <tglx@...utronix.de>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Andy, thanks for the great patch! It works for me, I've tested it on top
of 5.5-rc7, no more RTC lost interrupts while using the "irqpoll"
parameter. So, feel free to add my:
Tested-by: Guilherme G. Piccoli <gpiccoli@...onical.com>
Cheers,
Guilherme
Powered by blists - more mailing lists