From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: [PATCH 11/11] x86: support up to 16Tb Date: Tue, 22 Jan 2013 07:20:00 -0800 (PST) Message-ID: <8a71a3c9-6712-4b0e-b7bd-c30aa64fcc54@default> References: <50FE7BF502000078000B82F8@nat28.tlf.novell.com> <50FE7EBD02000078000B8355@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50FE7EBD02000078000B8355@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] > Subject: [Xen-devel] [PATCH 11/11] x86: support up to 16Tb > > Since TMEM doesn't currently cope with the full 1:1 map not always > being visible, it gets forcefully disabled in that case. > > Signed-off-by: Jan Beulich I agree this is the correct short-term (and maybe mid-term) answer. Anyone who can afford to fill their machine with more than 5TiB of RAM is likely not very interested in memory overcommit technologies :-) at least for the next year or three. Cloud providers may be an exception but I'd imagine most of those are buying small- to mid-range machines to optimize cost/performance, rather than behemoths that expand to 5TiB+ which are highly performant but often not cost-effective. Longer term, zcache in Linux (which is a tmem-based technology) successfully uses kmap/kunmap to run on 32-bit Linux OS's so I'd imagine a similar technique could be used in Xen? In any case, thanks Jan for remembering to handle tmem. One nit below... Acked-by: Dan Magenheimer > + if ( opt_tmem ) > + { > + printk(XENLOG_WARNING "Forcing TMEM off\n"); > + opt_tmem = 0; > + } > + } Maybe a bit more descriptive? I.e. "TMEM physical RAM limit exceeded, disabling TMEM".