From: Jeremy Fitzhardinge <jeremy@xensource.com>
To: LAPLACE Cyprien <cyprien.laplace@trango-systems.com>
Cc: virtualization@lists.linux-foundation.org,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: SMP lockup in virtualized environment
Date: Tue, 24 Apr 2007 11:04:15 -0700 [thread overview]
Message-ID: <462E469F.6060502@xensource.com> (raw)
In-Reply-To: <462E4223.1050109@trango-systems.com>
LAPLACE Cyprien wrote:
> I wonder how the guest domain can be denied timer interrupts for such a
> long time ? The only reason I see is that the guest domain is not
> scheduled at all (host domain or another higher priority guest running).
>
> Now in SMP host and guest, what happens if a guest CPU is not scheduled
> for a while ?
>
I think this mostly happens when you're doing an inherently
time-stealing thing, like pausing vcpus or suspend/resume. But I guess
it could happen with a low-prio domain/vcpu on a busy system.
> An example: in kernel/pid.c:alloc_pid(), if one of the guest CPUs is
> descheduled when holding the pidmap_lock, what happens to the other
> guest CPUs who want to alloc/free pids ? Are they blocked too ?
>
Yep; its a problem. If a vcpu holding locks and not running, then
everyone else will be prevented from taking those locks. If you have a
very busy system, then presumably all the vcpus will be similarly loaded
and the fact that it takes a long time to get locks just means you're
trying to run too many vcpus for your hardware's capacity.
The other problem is if you've got two vcpus sharing one real cpu, and
vcpu A spins while waiting for vcpu B to release a lock, and vcpu B is
waiting for A to get off the physical CPU. I don't know how often this
is a real problem in practice.
J
next prev parent reply other threads:[~2007-04-24 18:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 17:45 SMP lockup in virtualized environment LAPLACE Cyprien
2007-04-24 18:04 ` Jeremy Fitzhardinge [this message]
2007-04-24 22:37 ` Chris Snook
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=462E469F.6060502@xensource.com \
--to=jeremy@xensource.com \
--cc=cyprien.laplace@trango-systems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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