Message-Id: <200403252226.i2PMQZu02326@owlet.beaverton.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
cc: Andi Kleen <ak@suse.de>, "Nakajima, Jun" <jun.nakajima@intel.com>,
       piggin@cyberone.com.au, linux-kernel@vger.kernel.org, akpm@osdl.org,
       kernel@kolivas.org, rusty@rustcorp.com.au, anton@samba.org,
       lse-tech@lists.sourceforge.net, mbligh@aracnet.com
Subject: Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3 
In-reply-to: Your message of "Thu, 25 Mar 2004 22:59:08 +0100."
             <20040325215908.GA19313@elte.hu> 
Date: Thu, 25 Mar 2004 14:26:35 -0800
From: Rick Lindsley <ricklind@us.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1112
Lines: 22

    There's no way the scheduler can figure out the scheduling and memory
    use patterns of the new tasks in advance.

True.  Four threads may want to stay on the same node because they are
sharing a lot of data and working on something in parallel, or they
may want to go to different nodes because the only thing they have in
common is a control structure that directs their (largely independent
but highly synchronized) efforts.

A while ago there was some effort at user-level page replication, which
meant you took a hit once but after that you'd effectively migrated a page
to your local memory.  The longer you stayed put, the more local your
RSS got.  I seem to recall some bugs or caveats, though.  Anybody know
the state of that?  It might take the burden off the scheduler using a
crystal ball and putting it on a 20/20-hindsight VM system instead.

Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/