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