Re: [Xen-devel] [PATCH 11/11] x86: support up to 16Tb

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.13 at 16:20, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> 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@xxxxxxxx>
> 
> 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@xxxxxxxxxx>

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel