All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Mason <ric.masonn@gmail.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: lsf@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC] Beyond NUMA
Date: Mon, 15 Apr 2013 08:39:06 +0800	[thread overview]
Message-ID: <516B4C2A.5010400@gmail.com> (raw)
In-Reply-To: <9f091f23-9314-422c-9f97-525ddefd483b@default>

Hi Dan,
On 04/12/2013 08:29 AM, Dan Magenheimer wrote:
> MM developers and all --
>
> It's a bit late to add a topic, but with such a great group of brains
> together, it seems worthwhile to spend at least some time speculating
> on "farther-out" problems.  So I propose for the MM track:
>
> Beyond NUMA
>
> NUMA now impacts even the smallest servers and soon, perhaps even embedded
> systems, but the performance effects are limited when the number of nodes
> is small (e.g. two).  As the number of nodes grows, along with the number
> of memory controllers, NUMA can have a big performance impact and the MM
> community has invested a huge amount of energy into reducing this problem.
>
> But as the number of memory controllers grows, the cost of the system
> grows faster.  This is classic "scale-up" and certain workloads will
> always benefit from having as many CPUs/cores and nodes as can be
> packed into a single system.  System vendors are happy to oblige because the
> profit margin on scale-out systems can be proportionally much much
> larger than on smaller commodity systems.  So the NUMA work will always
> be necessary and important.
>
> But as scale-out grows to previously unimaginable levels, an increasing
> fraction of workloads are unable to adequately benefit to compensate
> for the non-linear increase in system cost.  And so more users, especially
> cost-sensitive users, are turning instead to scale-out to optimize
> cost vs benefit for their massive data centers.  Recent examples include
> HP's Moonshot and Facebook's "Group Hug".  And even major data center
> topology changes are being proposed which use super-high-speed links to
> separate CPUs from RAM [1].
>
> While filesystems and storage have long ago adapted to handle large
> numbers of servers effectively, the MM subsystem is still isolated,
> managing its own private set of RAM, independent of and completely
> partitioned from the RAM of other servers.  Perhaps we, the Linux
> MM developers, should start considering how MM can evolve in this
> new world.  In some ways, scale-out is like NUMA, but a step beyond.
> In other ways, scale-out is very different.  The ramster project [2]
> in the staging tree is a step in the direction of "clusterizing" RAM,
> but may or may not be the right step.

If I configure UMA machine to fake numa, is there benefit or impact 
performance?

>
> Discuss.
>
> [1] http://allthingsd.com/20130410/intel-wants-to-redesign-your-server-rack/
> [2] http://lwn.net/Articles/481681/
>
> (see y'all next week!)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=ilto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2013-04-15  0:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12  0:29 [LSF/MM TOPIC] Beyond NUMA Dan Magenheimer
2013-04-14 21:39 ` James Bottomley
2013-04-14 23:49   ` [Lsf] " Dave Chinner
2013-04-15  1:52     ` James Bottomley
2013-04-15 20:47       ` Dan Magenheimer
2013-04-15 20:50         ` H. Peter Anvin
2013-04-15 15:28   ` Dan Magenheimer
2013-04-15  0:39 ` Ric Mason [this message]

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=516B4C2A.5010400@gmail.com \
    --to=ric.masonn@gmail.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf@lists.linux-foundation.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.