| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: non-zero order allocations in shadow code may prevent li
>>> 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().
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home