From: Sander Eikelenboom <linux@eikelenboom.it>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
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, 01 Dec 2015 23:51:50 +0100 [thread overview]
Message-ID: <1fbcd101856fde55adafb200b82ee396@eikelenboom.it> (raw)
In-Reply-To: <565CD3A7.1060006@oracle.com>
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).
--
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 22:55 UTC|newest]
Thread overview: 18+ 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
[not found] ` <20151130214513.GF14317@char.us.oracle.com>
2015-11-30 21:46 ` [Xen-devel] " Sander Eikelenboom
2015-11-30 22:54 ` 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:30 ` Sander Eikelenboom
2015-12-01 23:41 ` Boris Ostrovsky
2015-12-01 23:44 ` Sander Eikelenboom
2015-12-02 10:04 ` Sander Eikelenboom
2015-12-01 22:51 ` Sander Eikelenboom [this message]
2015-12-01 23:05 ` Boris Ostrovsky
2015-11-30 22:47 ` Sander Eikelenboom
2015-12-02 14:15 ` David Vrabel
2015-12-02 14:55 ` David Vrabel
2015-12-02 17:30 ` Sander Eikelenboom
[not found] <CAPQw5rmKWRoYQa4Lt9ZyBzKuK3kKSXkd_YoYWO_cVfKoL+EMbw@mail.gmail.com>
2015-12-14 21:07 ` 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=1fbcd101856fde55adafb200b82ee396@eikelenboom.it \
--to=linux@eikelenboom.it \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox