All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 11/11] x86: support up to 16Tb
Date: Tue, 22 Jan 2013 07:20:00 -0800 (PST)	[thread overview]
Message-ID: <8a71a3c9-6712-4b0e-b7bd-c30aa64fcc54@default> (raw)
In-Reply-To: <50FE7EBD02000078000B8355@nat28.tlf.novell.com>

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


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

  reply	other threads:[~2013-01-22 15:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22 10:45 [PATCH 00/11] x86: support up to 16Tb Jan Beulich
2013-01-22 10:50 ` [PATCH 02/11] x86: extend frame table virtual space Jan Beulich
2013-01-22 10:50 ` [PATCH 03/11] x86: re-introduce map_domain_page() et al Jan Beulich
2013-01-22 10:51 ` [PATCH 04/11] x86: properly use map_domain_page() when building Dom0 Jan Beulich
2013-01-22 10:52 ` [PATCH 05/11] x86: consolidate initialization of PV guest L4 page tables Jan Beulich
2013-01-22 10:53 ` [PATCH 06/11] x86: properly use map_domain_page() during domain creation/destruction Jan Beulich
2013-01-22 10:55 ` [PATCH 07/11] x86: properly use map_domain_page() during page table manipulation Jan Beulich
2013-01-22 10:55 ` [PATCH 08/11] x86: properly use map_domain_page() in nested HVM code Jan Beulich
2013-01-22 10:56 ` [PATCH 09/11] x86: properly use map_domain_page() in miscellaneous places Jan Beulich
2013-01-22 10:57 ` [PATCH 10/11] tmem: partial adjustments for x86 16Tb support Jan Beulich
2013-01-22 17:55   ` Dan Magenheimer
2013-01-22 10:57 ` [PATCH 11/11] x86: support up to 16Tb Jan Beulich
2013-01-22 15:20   ` Dan Magenheimer [this message]
2013-01-22 15:31     ` Jan Beulich
2013-01-22 10:58 ` [PATCH 12/11] x86: debugging code for testing 16Tb support on smaller memory systems Jan Beulich
2013-01-23 14:26   ` [PATCH v2] " Jan Beulich
2013-01-23 15:18     ` Keir Fraser
2013-01-24 11:36     ` Tim Deegan
2013-01-24 12:23       ` Jan Beulich
2013-01-24 12:36         ` Tim Deegan
2013-01-22 20:13 ` [PATCH 00/11] x86: support up to 16Tb Keir Fraser
2013-01-23  9:33 ` Keir Fraser
2013-01-23  9:56   ` Jan Beulich
2013-01-23 10:16     ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a71a3c9-6712-4b0e-b7bd-c30aa64fcc54@default \
    --to=dan.magenheimer@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.