linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: rientjes@cs.washington.edu, akpm@osdl.org, linux-mm@kvack.org,
	nickpiggin@yahoo.com.au, ak@suse.de, mbligh@google.com,
	rohitseth@google.com, menage@google.com
Subject: Re: [RFC] memory page_alloc zonelist caching speedup
Date: Tue, 10 Oct 2006 12:35:55 -0700	[thread overview]
Message-ID: <20061010123555.21996034.pj@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0610101001480.927@schroedinger.engr.sgi.com>

Christoph wrote:
> Could it be worth to investigate more radical ideas? This gets way too 
> complicated for me. Maybe drop the whole zone list generation idea and 
> iterate over nodes in another way?

Worth some thought.

I'll be surprised if this eliminates the usefulness of something
like this zonelist caching patch, however.

Sooner or later, regardless of what shape data structures we have,
we end up having to examine a bunch of nodes when allocating for
workloads or numa emulated configurations that make heavy use of
off-node allocations.

And when that happens, we end up with an N-squared information
flow problem, needing to get information or at least hints as to
which nodes have free pages to the tasks trying to allocate those
pages.

But we really would rather not pay the price of even a linear
scan over N nodes, in either the tasks freeing pages, nor in the
tasks allocating them.

The best I've been able to do, in this patch, is:
 1) compact the information, to minimize the cache line footprint, and
 2) have the allocators get by on incomplete information, essentially
    doing the first scan based on remembering which nodes were
    recently noticed to be full.

I predict that regardless of the shape (zonelists, nodemasks or
whatever) of the placement information coming into the core
routine of our allocator, we will still need some sort of caching
like this, bolted onto the side, for the cases making heavy use
of off-node allocations.

So I would not use disgust at the added complexity of this zonelist
caching patch to justify changing the fundamental zonelist structures
used to drive the kernel allocator.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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-10-10 19:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 10:54 [RFC] memory page alloc minor cleanups Paul Jackson, Paul Jackson
2006-10-09 10:54 ` [RFC] memory page_alloc zonelist caching speedup Paul Jackson
2006-10-09 18:12   ` Andrew Morton
2006-10-09 22:02     ` Paul Jackson
2006-10-10  4:51       ` Paul Jackson
2006-10-10  6:34         ` David Rientjes
2006-10-10  7:03           ` Paul Jackson
2006-10-10 17:07             ` Christoph Lameter
2006-10-10 19:35               ` Paul Jackson [this message]
2006-10-10  6:45       ` Paul Jackson
2006-10-09 11:08 ` [RFC] memory page alloc minor cleanups Christoph Lameter
2006-10-09 11:50   ` Paul Jackson
2006-10-09 17:12     ` Christoph Lameter
2006-10-09 13:11 ` Nick Piggin
2006-10-09 20:24   ` Paul Jackson
2006-10-10  1:45     ` Paul Jackson

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=20061010123555.21996034.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@google.com \
    --cc=menage@google.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rientjes@cs.washington.edu \
    --cc=rohitseth@google.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