All of lore.kernel.org
 help / color / mirror / Atom feed
From: tgh <tianguanhua@ncic.ac.cn>
To: Emmanuel Ackaouy <ack@xensource.com>
Cc: Ryan Harper <ryanh@us.ibm.com>,
	"Petersson, Mats" <Mats.Petersson@amd.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	David Pilger <pilger.david@gmail.com>,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>
Subject: Re: Re: NUMA and SMP
Date: Tue, 20 Mar 2007 21:10:10 +0800	[thread overview]
Message-ID: <45FFDD32.8030607@ncic.ac.cn> (raw)
In-Reply-To: <8790346913e7b2e96fdc58199e039895@xensource.com>

I am puzzled ,what is the page migration?
Thank you in advance


Emmanuel Ackaouy 写道:
> On the topic of NUMA:
>
> I'd like to dispute the assumption that a NUMA-aware OS can actually
> make good decisions about the initial placement of memory in a
> reasonable hardware ccNUMA system.
>
> How does the OS know on which node a particular chunk of memory
> will be most accessed? The truth is that unless the application or
> person running the application is herself NUMA-aware and can provide
> placement hints or directives, the OS will seldom beat a round-robin /
> interleave or random placement strategy.
>
> To illustrate, consider an app which lays out a bunch of data in memory
> in a single thread and then spawns worker threads to process it.
>
> Is the OS to place memory close to the initial thread? How can it 
> possibly
> know how many threads will eventually process the data?
>
> Even if the OS knew how many threads will eventually crunch the data,
> it cannot possibly know at placement time if each thread will work on an
> assigned data subset (and if so, which one) or if it will act as a 
> pipeline
> stage with all the data being passed from one thread to the next.
>
> If you go beyond initial memory placement or start considering memory
> migration, then it's even harder to win because you have to pay copy
> and stall penalties during migrations. So you have to be real smart
> about predicting the future to do better than your ~10-40% memory
> bandwidth and latency hit associated with doing simple memory
> interleaving on a modern hardware-ccNUMA system.
>
> And it gets worse for you when your app is successfully taking advantage
> of the memory cache hierarchy because its performance is less impacted
> by raw memory latency and bandwidth.
>
> Things also get more difficult on a time-sharing host with competing
> apps.
>
> There is a strong argument for making hypervisors and OSes NUMA
> aware in the sense that:
> 1- They know about system topology
> 2- They can export this information up the stack to applications and 
> users
> 3- They can take in directives from users and applications to 
> partition the
> host and place some threads and memory in specific partitions.
> 4- They use an interleaved (or random) initial memory placement strategy
> by default.
>
> The argument that the OS on its own -- without user or application
> directives -- can make better placement decisions than round-robin or
> random placement is -- in my opinion -- flawed.
>
> I also am skeptical that the complexity associated with page migration
> strategies would be worthwhile: If you got it wrong the first time, what
> makes you think you'll do better this time?
>
> Emmanuel.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

  parent reply	other threads:[~2007-03-20 13:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-14 11:55 NUMA and SMP David Pilger
2007-01-14 19:00 ` Ryan Harper
2007-01-15 17:21 ` Anthony Liguori
2007-01-16 10:47   ` Petersson, Mats
2007-01-16 13:55     ` Emmanuel Ackaouy
2007-01-16 14:19       ` Petersson, Mats
2007-01-16 16:13         ` Emmanuel Ackaouy
2007-01-16 16:30           ` Petersson, Mats
2007-03-20 13:10       ` tgh [this message]
2007-03-20 13:19         ` Petersson, Mats
2007-03-20 13:49           ` tgh
2007-03-20 15:50             ` Petersson, Mats
2007-03-20 16:45               ` Ryan Harper
2007-03-20 16:47                 ` Petersson, Mats
2007-03-20 13:51         ` Daniel Stodden
2007-03-21  1:08           ` tgh
2007-03-21  2:45             ` Daniel Stodden
2007-03-22  1:16               ` tgh
2007-03-22 10:42                 ` Daniel Stodden
2007-03-22 12:13                   ` tgh
2007-03-22 12:28                     ` Daniel Stodden
2007-03-22 13:02                       ` Ryan Harper
2007-03-22 14:56                         ` Daniel Stodden
2007-03-22 15:12                           ` Ryan Harper
2007-03-22 15:38                             ` Daniel Stodden
2007-03-22 16:01                               ` Ryan Harper
2007-03-22 16:22                                 ` Daniel Stodden
2007-03-22 17:02                                   ` Ryan Harper
2007-03-23  5:47                                     ` tgh
2007-03-23 14:42                                       ` Ryan Harper
2007-03-23 14:48                                         ` Petersson, Mats
2007-03-28  1:50                                           ` tgh
2007-03-28  2:01                                             ` Ryan Harper
2007-03-28 21:25                                   ` The context switch overhead comparison between vmexit/vmentry and hypercall Liang Yang
2007-01-16 14:51   ` Re: NUMA and SMP ron minnich

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=45FFDD32.8030607@ncic.ac.cn \
    --to=tianguanhua@ncic.ac.cn \
    --cc=Mats.Petersson@amd.com \
    --cc=ack@xensource.com \
    --cc=aliguori@linux.vnet.ibm.com \
    --cc=pilger.david@gmail.com \
    --cc=ryanh@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /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.