From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
david.vrabel@citrix.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xen.org
Subject: Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.
Date: Tue, 1 Dec 2015 18:05:41 -0500 [thread overview]
Message-ID: <565E27C5.9050703@oracle.com> (raw)
In-Reply-To: <1fbcd101856fde55adafb200b82ee396@eikelenboom.it>
On 12/01/2015 05:51 PM, Sander Eikelenboom wrote:
> 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.
>>
>>
>>>
>>> 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.
>>
>
> Could it be .. that with your fixup:
> xen/events: Always allocate legacy interrupts on PV guests
> (b4ff8389ed14b849354b59ce9b360bdefcdbf99c)
> for commit:
> x86/irq: Probe for PIC presence before allocating descs for legacy
> IRQs
> (8c058b0b9c34d8c8d7912880956543769323e2d8)
>
> that we now have the situation described in the commit message of
> 8c058b0b9c, but now for Xen PV instead of
> Hyper-V ?
> (seems both Xen and Hyper-V want to achieve the same but have
> different competing implementations ?)
>
> (BTW 8c058b0b9c has a CC for stable ... so could be destined to cause
> more trouble).
You mean my statement that irq 1 looks bad? That was a red herring, it
should be fine.
-boris
>
> --
> Sander
>
>
>>>>>
>>>>> 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
>>>>>
>>>>>
next prev parent reply other threads:[~2015-12-01 23:05 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-28 15:47 linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu Sander Eikelenboom
2015-11-30 21:45 ` Konrad Rzeszutek Wilk
2015-11-30 21:46 ` [Xen-devel] " Sander Eikelenboom
2015-11-30 22:54 ` Boris Ostrovsky
2015-11-30 22:54 ` [Xen-devel] " Boris Ostrovsky
2015-11-30 22:55 ` Sander Eikelenboom
2015-12-01 22:47 ` Boris Ostrovsky
2015-12-01 23:00 ` Sander Eikelenboom
2015-12-01 23:19 ` Boris Ostrovsky
2015-12-01 23:19 ` [Xen-devel] " Boris Ostrovsky
2015-12-01 23:30 ` Sander Eikelenboom
2015-12-01 23:41 ` Boris Ostrovsky
2015-12-01 23:44 ` Sander Eikelenboom
2015-12-01 23:44 ` [Xen-devel] " Sander Eikelenboom
2015-12-02 10:04 ` Sander Eikelenboom
2015-12-02 10:04 ` Sander Eikelenboom
2015-12-01 23:41 ` Boris Ostrovsky
2015-12-01 23:30 ` Sander Eikelenboom
2015-12-01 23:00 ` Sander Eikelenboom
2015-12-01 22:47 ` Boris Ostrovsky
2015-11-30 22:55 ` Sander Eikelenboom
2015-12-01 22:51 ` Sander Eikelenboom
2015-12-01 22:51 ` [Xen-devel] " Sander Eikelenboom
2015-12-01 23:05 ` Boris Ostrovsky
2015-12-01 23:05 ` Boris Ostrovsky [this message]
2015-11-30 21:46 ` Sander Eikelenboom
2015-11-30 22:47 ` Sander Eikelenboom
2015-11-30 22:47 ` [Xen-devel] " Sander Eikelenboom
2015-12-02 14:15 ` David Vrabel
2015-12-02 14:15 ` [Xen-devel] " David Vrabel
2015-12-02 14:55 ` David Vrabel
2015-12-02 14:55 ` [Xen-devel] " David Vrabel
2015-12-02 17:30 ` Sander Eikelenboom
2015-12-02 17:30 ` Sander Eikelenboom
-- strict thread matches above, loose matches on Subject: below --
2015-12-14 19:48 Eric Shelton
2015-12-14 21:07 ` [Xen-devel] " Sander Eikelenboom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=565E27C5.9050703@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@eikelenboom.it \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.