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