From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: long latency of domain shutdown
Date: Thu, 08 May 2008 15:29:07 +0100 [thread overview]
Message-ID: <48232A53.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C448B25B.2073E%keir.fraser@eu.citrix.com>
>>> Keir Fraser <keir.fraser@eu.citrix.com> 08.05.08 14:36 >>>
>> But really, rather than introducing (and fixing) the hack here I'd much
>> prefer a generic solution to the problem, and you didn't say a word on
>> the thoughts I had on that (but in a mail a couple of days ago you
>> indicated you might get around doing something in that area yourself,
>> so I half way implied you may have a mechanism in mind already).
>
>I don't have a very clear plan, except that some kind of continuation
>(basically encoding of how far we got) must be encoded in the page_info
>structure. We should be able to find spare bits for a page which is in this
>in-between state.
Hmm, storing this in page_info seems questionable to me. It'd be at
least 18 bits (on x86-64) that we'd need. I think this rather has to go
into struct vcpu.
But what worries me more is that (obviously) any affected page will
have to have its PGT_validated bit kept clear, which could lead to
undesirable latencies in spin loops on other vcpus waiting for it to
become set. In the worst case this could lead to deadlocks (at least
in the UP case or when multiple vCPU-s of one guest are pinned to
the same physical CPU) afaics. Perhaps this part could indeed be
addressed with a new PGT_* bit, upon which waiters could exit
their spin loops and consider themselves preempted.
Jan
next prev parent reply other threads:[~2008-05-08 14:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48189781.76E4.0078.0@novell.com>
[not found] ` <C43E4040.2022A%keir.fraser@eu.citrix.com>
2008-05-08 9:58 ` long latency of domain shutdown Jan Beulich
2008-05-08 10:12 ` Keir Fraser
2008-05-08 10:39 ` Jan Beulich
2008-05-08 10:52 ` Keir Fraser
2008-05-08 11:13 ` Jan Beulich
2008-05-08 12:11 ` Keir Fraser
2008-05-08 12:33 ` Jan Beulich
2008-05-08 12:36 ` Keir Fraser
2008-05-08 14:29 ` Jan Beulich [this message]
2008-05-08 14:38 ` Keir Fraser
2008-05-09 10:23 ` Jan Beulich
2008-05-09 10:29 ` Keir Fraser
2008-04-28 13:45 Jan Beulich
2008-04-28 13:59 ` Keir Fraser
2008-04-28 14:30 ` Jan Beulich
2008-04-28 14:42 ` Keir Fraser
2008-05-14 15:54 ` Jan Beulich
2008-05-14 16:05 ` Jan Beulich
2008-05-14 16:08 ` Keir Fraser
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=48232A53.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.