[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.