WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: non-zero order allocations in shadow code may prevent li

>>> "Jan Beulich" <jbeulich@xxxxxxxxxx> 27.09.07 14:58 >>>
>>>> Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx> 27.09.07 14:07 >>>
>>At 12:19 +0100 on 27 Sep (1190895561), Jan Beulich wrote:
>>> So then I'll go ahead with implementing the described change (I'm actually
>>> intending to have shadow_prealloc() take not just an order, but also a count
>>> parameter - in a number of places it is being called with SHADOW_MAX_ORDER
>>> for no reason other than wanting 3 or 4 single pages).
>>
>>shadow_prealloc could just as easily take no arguments and always free
>>four pages in the highest order that's in use.  There's no real benefit
>>from fine-tuning it as the operations that free shadow memory operate in
>>much bigger increments anyway.
>
>While doing so I realized that this would fit well with the suggested HVM 
>related
>changes in my other response. However, you seem to indicate that such
>changes aren't worth it from a performance perspective, so I'm not sure it'd
>be worth. Otoh, in a long lived production environment fragmentation is likely
>to become a significant issue, and it is certainly not desirable to have good
>chances of HVM domain creation starting to fail after a system has been up
>for a long time (in theory it might be necessary to balloon out of Dom0 three
>quarters of the installed physical memory plus one quarter of the to be
>allocated amount in order to guarantee that shadow allocation can succeed).
>But I also agree that any attempt to change this without changing the parts of
>the shadow code that depend on non-zero order pages will only reduce the
>likelihood of running into the problem, it won't eliminate it. So I guess for a
>first cut I'll go with your suggestion of removing the 'order' parameter of
>shadow_prealloc().

An additional consideration: Allowing to specify order and count in the call
to shadow_prealloc() might also help to avoid flushes, since in many cases
the need is really just for a number of single pages, not one big one.

Jan


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