From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: qemu-upstream triggering OOM killer
Date: Thu, 16 Feb 2017 10:38:39 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1702161037290.9566@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <58A5E155020000780013AD78@prv-mh.provo.novell.com>
On Thu, 16 Feb 2017, Jan Beulich wrote:
> >>> On 16.02.17 at 16:23, <JBeulich@suse.com> wrote:
> >>>> On 14.02.17 at 15:56, <anthony.perard@citrix.com> wrote:
> >> On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
> >>> Not so far. It appears to happen when grub clears the screen
> >>> before displaying its graphical menu, so I'd rather suspect an issue
> >>> with a graphics related change (the one you pointed out isn't).
> >>
> >> I tried to reproduce this, by limiting the amount of memory available to
> >> qemu using cgroups, but about 44MB of memory is enough to boot a guest
> >> (tried Ubuntu and Debian).
> >
> > Okay, not a qemuu regression after all, but a libxc one. It just so
> > happens that qemut tries to allocate a much larger amount, which
> > triggers mmap() failure earlier and hence doesn't manage to trigger
> > the oom killer. Patch (almost) on its way.
>
> Patch sent, allowing that guest to get further (and Windows to
> properly boot). However, now the guest is stuck right at the point
> where X wants to switch to its designated video mode, with qemu
> (for somewhere between half a minute and a minute) consuming
> one full CPU's bandwidth. Once qemu's CPU consumption went
> down, no further progress is being made though.
>
> Again I'd be thankful for hints on how to debug such a situation.
I would bisect it. It's probably due to a change in the cirrus vga code
or common vga code. It might be worth testing with stdvga=1 to narrow it
down.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-16 18:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 14:57 qemu-upstream triggering OOM killer Jan Beulich
2017-02-09 22:24 ` Stefano Stabellini
2017-02-10 9:54 ` Jan Beulich
2017-02-14 14:56 ` Anthony PERARD
2017-02-15 9:07 ` Jan Beulich
2017-02-16 15:23 ` Jan Beulich
2017-02-16 16:28 ` Jan Beulich
2017-02-16 18:38 ` Stefano Stabellini [this message]
2017-02-17 7:08 ` Jan Beulich
2017-02-17 18:39 ` Stefano Stabellini
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=alpine.DEB.2.10.1702161037290.9566@sstabellini-ThinkPad-X260 \
--to=sstabellini@kernel.org \
--cc=JBeulich@suse.com \
--cc=anthony.perard@citrix.com \
--cc=xen-devel@lists.xenproject.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.