WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] sparse M2P table

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 16.09.09 15:40 >>>
>Ah, I'd forgotten we guarantee that the M2P is made up of aligned 2MB
>extents. That given I don't think we should bother having mapping holes
>after all -- the cost of the extra page-directory entries is only ~4kB per
>1GB of M2P. What I would instead do is just alias the first 2MB extent of
>the M2P into every 'empty' 2MB extent of the M2P (this is just a handy
>'safe' 2MB piece of memory to map in, so that (a) tools requests to map the
>M2P just continue to work; and (b) so that we have no doubts about guests
>possibly not handling faults on accesses into the M2P). Aliasing the first
>M2P extent like that just avoids us burning another 2MB for no good reason,
>to map regions of the M2P which really only contain 'garbage'.
>
>Does that sound good?

Indeed, it doesn't really matter *what* gets mapped there. I wouldn't,
however, strictly stick to the first chunk - if there's a 1G chunk, and later
a 1G hole, I'd prefer using the existing 1G chunk there, and iteratively
populate it with 2M chunks only when no 1G chunk was previously
allocated. Perhaps (depending on what turns out simpler) I might also
just use the most recent chunk for sticking in a hole...

Jan


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