Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

[Sander Eikelenboom <linux@eikelenboom.it>]

On 2015-11-30 23:54, Boris Ostrovsky wrote:
> On 11/30/2015 04:46 PM, Sander Eikelenboom wrote:
>> On 2015-11-30 22:45, Konrad Rzeszutek Wilk wrote:
>>> On Sat, Nov 28, 2015 at 04:47:43PM +0100, Sander Eikelenboom wrote:
>>>> Hi all,
>>>> 
>>>> I have just tested a 4.4-rc2 kernel (current linus tree) + the tip 
>>>> tree
>>>> pulled on top.
>>>> 
>>>> Running this kernel under Xen on PV-guests with multiple vcpus goes 
>>>> well (on
>>>> idle < 10% cpu usage),
>>>> but a guest with only a single vcpu doesn't idle at all, it seems a 
>>>> kworker
>>>> thread is stuck:
>>>> root       569 98.0  0.0      0     0 ?        R    16:02 12:47
>>>> [kworker/0:1]
>>>> 
>>>> Running a 4.3 kernel works fine with a single vpcu, bisecting would 
>>>> probably
>>>> quite painful since there were some breakages this merge window with 
>>>> respect
>>>> to Xen pv-guests.
>>>> 
>>>> There are some differences in the diff's from booting a 4.3, 
>>>> 4.4-single,
>>>> 4.4-multi cpu boot:
>>> 
>>> Boris has been tracking a bunch of them. I am attaching the latest 
>>> set of
>>> patches I've to carry on top of v4.4-rc3.
>> 
>> Hi Konrad,
>> 
>> i will test those, see if it fixes all my issues and report back
> 
> They shouldn't help you ;-( (and I just saw a message from you 
> confirming this)
> 
> The first one fixes a 32-bit bug (on bare metal too). The second fixes
> a fatal bug for 32-bit PV guests. The other two are code
> improvements/cleanup.

One of these patches also fixes a bug i was having with a 
pci-passthrough device in
a HVM that wasn't working (depending on which dom0-kernel i was using 
(4.3 or 4.4)),
but didn't report yet.

Fingers crossed but i think this pv-guest single vcpu issue is the last 
i'm troubled by for now ;)

--
Sander

> 
>> 
>> Thanks :)
>> 
>> -- Sander
>> 
>>>> Between 4.3 and 4.4-single:
>>>> 
>>>> -NR_IRQS:4352 nr_irqs:32 16
>>>> +Using NULL legacy PIC
>>>> +NR_IRQS:4352 nr_irqs:32 0
> 
> This is fine, as long as you have 
> b4ff8389ed14b849354b59ce9b360bdefcdbf99c.
> 
>>>> 
>>>> -cpu 0 spinlock event irq 17
>>>> +cpu 0 spinlock event irq 1
> 
> This is strange. I wouldn't expect spinlocks to use legacy irqs.
> 
>>>> 
>>>> and later on:
>>>> 
>>>> -hctosys: unable to open rtc device (rtc0)
>>>> +rtc_cmos rtc_cmos: hctosys: unable to read the hardware clock
>>>> 
>>>> +genirq: Flags mismatch irq 8. 00000000 (hvc_console) vs. 00000000 
>>>> (rtc0)
>>>> +hvc_open: request_irq failed with rc -16.
>>>> +Warning: unable to open an initial console.
>>>> 
>>>> 
>>>> between 4.4-single and 4.4-multi:
>>>> 
>>>>  Using NULL legacy PIC
>>>> -NR_IRQS:4352 nr_irqs:32 0
>>>> +NR_IRQS:4352 nr_irqs:48 0
> 
> This is probably OK too since nr_irqs depend on number of CPUs.
> 
> I think something is messed up with IRQ. I saw last week something
> from setup_irq() generating a stack dump (warninig) for rtc_cmos but
> it appeared harmless at that time and now I don't see it anymore.
> 
> -boris
> 
> 
>>>> 
>>>> and later on:
>>>> 
>>>> -rtc_cmos rtc_cmos: hctosys: unable to read the hardware clock
>>>> +hctosys: unable to open rtc device (rtc0)
>>>> 
>>>> -genirq: Flags mismatch irq 8. 00000000 (hvc_console) vs. 00000000 
>>>> (rtc0)
>>>> -hvc_open: request_irq failed with rc -16.
>>>> -Warning: unable to open an initial console.
>>>> 
>>>> attached:
>>>>     - dmesg with 4.3 kernel with 1 vcpu
>>>>     - dmesg with 4.4 kernel with 1 vpcu
>>>>     - dmesg with 4.4 kernel with 2 vpcus
>>>>     - .config of the 4.4 kernel is attached.
>>>> 
>>>> -- Sander
>>>> 
>>>>