[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] long latency of domain shutdown


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 08 May 2008 13:11:21 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 08 May 2008 05:12:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcixBKBz3wHSwhz3Ed28OwAX8io7RQ==
  • Thread-topic: [Xen-devel] long latency of domain shutdown

On 8/5/08 12:13, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> Nor am I convinced about how much potential time-saving
>> there is to be had here.
> 
> I'm not seeing any time saving here. The other thing I brought up
> was just an unrelated item pointing out potential for code
> simplification.

Ah, yes, I see.

The approach looks plausible. I think in its current form it will leave
zombie L2/L3 pages hanging around and the domain will never actually
properly die (e.g., still will be visible with the 'q' key). Because
although you do get around to doing free_lX_table(), the type count and ref
count of the L2/L3 pages will not drop to zero because the dead L3/L4 page
never actually dropped its references properly.

In actuality, since we know that we never have 'cross-domain' pagetable type
references, we should actually be able to zap pagetable reference counts to
zero. The only reason we don't do that right now is really because it
provides good debugging info to see whether a domain's refcounts have got
screwed up. But that would not prevent us doing something faster for NDEBUG
builds, at least.

Does that make sense?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.