[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] sparse M2P table



On 16/09/2009 13:49, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> Ah okay, that makes more sense! I think M2P should be mapped sparsely and we
>> should expect guests to deal with it. We can revise that opinion if we find
>> strong reason to do otherwise. It's certainly what I was intending to do.
> 
> So for domain save, would you think that passing out zeroes for the holes
> in the output of XENMEM_machphys_mfn_list is a reasonable thing to do,
> with the expectation that the tools would split up their mapping request
> when encountering zeroes (single mmap(), but multiple subsequent calls
> through privcmd)?
> 
> Or shouldn't the tools perhaps not even do this with a single mmap()
> anymore, as the table can be pretty much unbounded now (I'm limiting
> it to 256G in my patches, but that doesn't need to be the final limit).
> 
> Also, will it be okay to leave the tools side stuff to be done by someone
> more familiar with them than I am?

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?

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.