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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 08.05.08 12:52 >>>
>On 8/5/08 11:39, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> No, here I mean having just RELMEM_xen and RELMEM_l{1,2,3,4}.
>> Then simply release Xen pages first, then l4...l1.
>> 
>> For the suggested workaround to reduce latency of relinquish_memory()
>> preemption, I simply mean utilizing the code to deal with circular
>> references also for releasing simple ones (that code path doesn't seem
>> to care to force the type count to zero, but as I understand that's no
>> problem since these pages end up being freed anyway, and that's
>> where the whole type_info field gets re-initialized - or was this
>> happening when the page gets allocated the next time).
>
>You've lost me. Either you are confused or I have forgotten the details of
>how that shutdown code works. Either is quite possible I suspect. :-)
>Basically I don't see how this avoids the recursive, and potentially rather
>expensive, teardown.

All I mean is a change like this:

--- 2008-05-08.orig/xen/arch/x86/mm.c
+++ 2008-05-08/xen/arch/x86/mm.c
@@ -1341,6 +1341,9 @@ static void free_l3_table(struct page_in
     l3_pgentry_t *pl3e;
     int           i;
 
+    if(d->arch.relmem == RELMEM_dom_l3)
+        return;
+
     pl3e = map_domain_page(pfn);
 
     for ( i = 0; i < L3_PAGETABLE_ENTRIES; i++ )
@@ -1364,6 +1367,9 @@ static void free_l4_table(struct page_in
     l4_pgentry_t *pl4e = page_to_virt(page);
     int           i;
 
+    if(d->arch.relmem == RELMEM_dom_l4)
+        return;
+
     for ( i = 0; i < L4_PAGETABLE_ENTRIES; i++ )
         if ( is_guest_l4_slot(d, i) )
             put_page_from_l4e(pl4e[i], pfn);

I tried it out on SLE10 SP1 (3.0.4 derived), and it appeared to work
and serve the purpose. With this, L3 and L2 tables are no longer
freed recursively upon an L4/L3 one dropping its last type reference,
but they rather get caught by the code that so far was only
responsible for dealing with circular references. The result is that
between individual full L2 tables (including the L1s hanging off of
them) being released there now is a preemption check. Up until now,
when the last L4 table got freed, everything hanging off of it needed
to be dealt with in a single non-preemptible chunk.

>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.

Jan


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