Re: Design question for PV superpage support

[Mick Jordan <Mick.Jordan@sun.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1909 bytes --]

On 03/03/09 06:33, Dan Magenheimer wrote:
>> In general, I think the guest should assume that large page 
>> mappings are 
>> merely an optimization that (a) might not be possible on domain start 
>> due to machine memory fragmentation and (b) that this condition might 
>> also occur on restore. Given these, it must always be prepared to 
>> function with 4K pages, which implies that it would need to preserve 
>> enough page table frame memory to be able revert from large 
>> to small pages.
>>
>> Mick
>>     
>
> Do you disagree with my assertion that use of 2MB pages is
> almost always an attempt to eke out a performance improvement,
> that emulating 2MB pages with fragmented 4KB pages is likely
> slower than just using 4KB pages to start with, and thus
> that "must always be prepared to function with 4KB pages"
> should NOT occur silently (if at all)?
>   
I agree with the first statement. I'm not sure what you mean by "emulate 
2MB pages with fragmented 4K pages" unless you assume nested page table 
support or you just mean falling back to 4K pages. As for whether a 
change should be silent, I'm less clear on that. I certainly wouldn't 
consider it a fatal condition requiring domain termination, That 
position is consistent with the "optimization not correctness" view of 
using large tables. However, a guest might want to indicate in some way 
that it has downgraded
> BTW, thinking ahead to ballooning with 2MB pages, are we prepared
> to assume that a relinquished 2MB page can't be fragmented?
> While this may be appealing for systems where nearly all
> guests are using 2MB pages, systems where the 2MB guest is
> an odd duck might suffer substantially by making that
> assumption.
>   
Agreed. All of this really only becomes an issue when memory is 
overcommitted. Unfortunately, that is precisely when 2MB machine 
contiguous pages are likely to be difficult to find.

Mick


[-- Attachment #1.2: Type: text/html, Size: 2405 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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