lkml.org 
[lkml]   [2015]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.
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
>>>>
>>>>


\
 
 \ /
  Last update: 2015-12-01 00:21    [W:0.070 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site