From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: [PATCH 10/11] tmem: partial adjustments for x86 16Tb support Date: Tue, 22 Jan 2013 09:55:43 -0800 (PST) Message-ID: References: <50FE7BF502000078000B82F8@nat28.tlf.novell.com> <50FE7E9F02000078000B8351@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50FE7E9F02000078000B8351@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Konrad Wilk List-Id: xen-devel@lists.xenproject.org > From: Jan Beulich [mailto:JBeulich@suse.com] > 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 > > 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@suse.com] > 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 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