RE: [Xen-ia64-devel] Virtual mem map

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年1月9日 18:43
>
>Le Lundi 09 Janvier 2006 06:45, Tian, Kevin a écrit :
>> From: Tristan Gingold
>>
>[...]
>> So in both cases you mentioned, extra structure to track mapping is
>> necessary. Maybe the difference is that you propose to use another simpler
>> structure (like a simple array/list) instead of multi-level page table? And
>> then modify all memmap related macros (like pfn_valid, page_to_pfn, etc) to
>> let them know existence of holes within memmap?
>Yes, here are more details on my original propositions:
>The structure is a 2-levels access:
>* The first access is an access to a table of offsets/length.
>* The offset is an offset to the page frame table, length is used only to
>check validity.
>
>I think this structure is simple enough to be fast.
>
>For memory usage:
>* Each entry of the first array describes 1GB of memory.  An entry is 32 bits.
>  16KB for the first array can describe 2**12 * 2**30 = 2**42 B of memory.
>  (Dan's machine physical memory is bellow 2**40).
>* I think 1GB of granule is good enough, unless you have a machine with very
>  small DIMM.  In this case, we can use 512MB or 256MB instead of 1GB.
>* 1GB is 2**16 to 2**18 pages.  Thus, the offset may be 18 bits and the length
>  14 bits (to be multiplied by 4).
>As a conclusion, the memory footprint is *very* small, maybe too small ?
>
>memmap related macros must be rewritten.
>
>Tristan.

Hi, Tristan,
        I think it's worthy of a try to see any explicit performance 
degradation there, since this is a quick approach to make virtual memmap 
working.

        Just a question, how do you define the granularity, static or dynamic? 
I'm not sure whether all types of ia64 boxes have a well aligned memory trunks. 
Take a quick example from layout posted by Dan:

(XEN) Init boot pages: 0x407df42a54 -> 0x407efe0008.
(XEN) Init boot pages: 0x407efe0068 -> 0x407efe3f82.
(XEN) Init boot pages: 0x407efe3fca -> 0x407effc008.
(XEN) Init boot pages: 0x407effc7e8 -> 0x407fd68000.
(XEN) Init boot pages: 0x407fda4000 -> 0x407fe10000.
(XEN) Init boot pages: 0x407fe80000 -> 0x407ffbc000.

        You could see all above 6 trunks within 1G and even 256Mb range. How do 
you manage to include them in your offset table then? I'm taking this example 
to just emphasize importance of the generality. Since we start to shoot this 
issue, better for a good solution which can live long time. Once you compile 
out a xen image, customer definitely want it to run on as many boxes as 
possible without re-compilation.

        Simple array always has better performance than more complex structures 
like multi-level page tables, however the former then faces with flexibility 
issue and thus born the latter.

        Other alternative like to use multi-level structure but without virtual 
mapping, which looks like current p2m implementation within Xen. However yes, 
that will bring more overhead when walking the structure...

Thanks,
Kevin
        

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