From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH 11/11] x86: support up to 16Tb
Date: Tue, 22 Jan 2013 15:31:32 +0000
Message-ID: <50FEBEE402000078000B85ED@nat28.tlf.novell.com>
References: <50FE7BF502000078000B82F8@nat28.tlf.novell.com>
	<50FE7EBD02000078000B8355@nat28.tlf.novell.com>
	<8a71a3c9-6712-4b0e-b7bd-c30aa64fcc54@default>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <8a71a3c9-6712-4b0e-b7bd-c30aa64fcc54@default>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel <xen-devel@lists.xen.org>, Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 22.01.13 at 16:20, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  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 <jbeulich@suse.com>
> 
> 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 <dan.magenheimer@oracle.com>

Hmm, an ack on this patch is sort of unexpected from you; I
would have hoped you would ack patch 10...

>> +        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".

Fine with me, patch updated.

Jan