[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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |