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

Re: [Xen-devel] [PATCH 10/11] tmem: partial adjustments for x86 16Tb support

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, January 22, 2013 8:32 AM
> To: xen-devel; Dan Magenheimer
> Cc: Konrad Wilk
> Subject: RE: [Xen-devel] [PATCH 11/11] x86: support up to 16Tb
> > Acked-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
> Hmm, an ack on this patch is sort of unexpected from you; I
> would have hoped you would ack patch 10...

Heh.  I was intrigued by the new domain_page_map_to_mfn()
and wanted to look deeper before acking patch 10.  So...

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Subject: [PATCH 10/11] tmem: partial adjustments for x86 16Tb support
> Despite the changes below, tmem still has code assuming to be able to
> directly access all memory, or mapping arbitrary amounts of not
> directly accessible memory. I cannot see how to fix this without
> converting _all_ its domheap allocations to xenheap ones. And even then
> I wouldn't be certain about there not being other cases where the "all
> memory is always mapped" assumption would be broken. Therefore, tmem
> gets disabled by the next patch for the time being if the full 1:1
> mapping isn't always visible.
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

IIUC, all the metadata will need to be allocated from the xenheap
and all "wholepage" accesses will need some kind of wrapper.
This will get messier with compression/deduplication, but
I'm thinking it will still be doable... sometime in the future
if/when users want/need memory overcommit on huge RAM systems.

In any case...

Acked-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>

Xen-devel mailing list



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