From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: long latency of domain shutdown Date: Thu, 08 May 2008 15:29:07 +0100 Message-ID: <48232A53.76E4.0078.0@novell.com> References: <48230F35.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 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