linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Andi Kleen <ak@suse.de>, Nick Piggin <nickpiggin@yahoo.com.au>,
	Marcelo Tosatti <marcelo@kvack.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Paul Jackson <pj@sgi.com>,
	dgc@sgi.com, Ravikiran G Thirumalai <kiran@scalex86.org>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	jes@sgi.com, Adam Litke <agl@us.ibm.com>,
	Mel Gorman <mel@csn.ul.ie>,
	steiner@sgi.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	akpm@osdl.org
Subject: Agenda for NUMA BOF @OLS & NUMA paper
Date: Mon, 10 Jul 2006 12:22:16 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0607101146170.5556@schroedinger.engr.sgi.com> (raw)

I have given a number of talks about various NUMA issues in the last 
months and tried to put the most important points together in a 
paper that begins to explain NUMA from scratch and then gets into some 
of the current issues. That paper is available at 
http://ftp.kernel.org/pub/linux/kernel/people/christoph/pmig/numamemory.pdf

Also there will be a NUMA BOF at the OLS on Thursday July 20th 18:00
in Room B. Some of the items that we may discuss are 
mentioned at the end of the paper.

Here is a one liner for each subject that may be useful to discuss. I'd be 
interested in hearing if there are any other issues that would need our 
attention or maybe some of these are not that important (Probably too many 
subjects already ...). Maybe this thread will allow those who will not be 
at the OLS to give us some imput.

A. Scalability
	- Lockless page cache / Concurrent page cache
	- Page Dirty handling (per node write throttling?)
	- How to effectively deal with per cpu data at high
		processor counts (f.e. 1024p)
	- Issues with the number of objects increasing by the
		power of two for higher counts (f.e. alien slab caches, 
		pagesets)
	- Effective per node slab reclaim for dentry and inode cache.
	- TLB pressure issues for large memory (huge pages???)

B. Page Migration
	- Automatic page migration approaches
	- Use of page migration to defragment memory
	- Memory hotplug and page migration

C. Memory Policies / Cpusets
	- Memory policies for the page cache?
	- Is the current situation okay that memory policies apply only
		to a single zone per node? (Okay for SGI because we only 
		have a single zone per node.... but how about others?)
	- Cpuset interference with subsystems managing their own
	  locality (vmalloc, slab, drivers).

D. Scheduler
	- Accounting for interrupt load?
	- Fairer cpu load balancing

General future vision things:
	- Increasing scheduler complexity for NUMA.
	- NUMA scheduler in user space that can be much more intelligent
		than possible in the kernel?
	- Functional overlap between memory policies and cpusets.
		Is there some scheme to unify these two and make it
		more general?
	- General memory balancing / dirty load balancing. Is there some
	  scheme to make it better and avoid some of the current manual
	  tuning?

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

             reply	other threads:[~2006-07-10 19:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-10 19:22 Christoph Lameter [this message]
2006-07-10 19:31 ` Jan-Benedict Glaw
2006-07-10 19:45   ` Christoph Lameter
2006-07-11  6:22 ` Andi Kleen
2006-07-11 15:43   ` Christoph Lameter

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=Pine.LNX.4.64.0607101146170.5556@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=agl@us.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=dgc@sgi.com \
    --cc=jes@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kiran@scalex86.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=steiner@sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox