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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Lundi 09 Janvier 2006 12:15, Tian, Kevin a écrit :
> 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?
At first static.  The only advantage of having dynamic granularity is to save 
memory.

> 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?
Such holes are due to EFI or reserved areas such as bootparams.  These holes 
may be really random.
By constructions these holes are not used.  We may check this by adding a
bit into the page structure.

Remember we need to have:
* a page entry for every physical page
* a quick access to such entry.
The non-virtual mem map is very good for both points, but it can spare a lot 
of memory.  I think my approach is better for memory usage but only slightly 
slower.

> 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.
Of course, I agree with you.

>       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