From: Paul Jackson <pj@sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, linux-mm@kvack.org, nickpiggin@yahoo.com.au,
rientjes@google.com, ak@suse.de, mbligh@google.com,
rohitseth@google.com, menage@google.com, clameter@sgi.com
Subject: Re: [RFC] memory page_alloc zonelist caching speedup
Date: Mon, 9 Oct 2006 21:51:25 -0700 [thread overview]
Message-ID: <20061009215125.619655b2.pj@sgi.com> (raw)
In-Reply-To: <20061009150259.d5b87469.pj@sgi.com>
pj wrote:
> I guess this means we add a counter to the zonelist_cache struct.
> Increment it each time we try to allocate a page from that zonelist.
> Trigger a zap (cache expiration) if the counter hits 1000, and clear
> the counter when we do the zap.
No, dang it. Not count allocs. Count frees.
My zonelist caching adapts immediately to another node being filled
up due to allocs, by turning on another bit in the fullzones bitmask.
But it doesn't adapt immediately to memory coming free.
An application could say free up a big chunk of memory on its
local node - perhaps by dropping the last reference to an anonymous
memory region.
It would then reasonably expect that new allocations would come
from the local node - right then - not starting some later time
up to one second in the future.
I think I'd need a per-node counter of frees, incremented on each free,
and checked by the zonelist caching to see if it should consider that
node no longer full.
-However- that forces a per-node reference in the zonelist caching
code as part of the scan for a free page. That is exactly what we
were trying to avoid!
No. Not count frees either. Don't count anything.
I do not see how to count anything related to allocs or frees and
then use that counter to throttle the zonelist caching, without
re-introducing the lousy cache line footprint that I just got done
shrinking.
That's why I like time based throttles. They are cheap. Dirt cheap.
Infinitely scalable. And stupid as a pet rock ;).
P.S. I don't think that the above application, expecting instant reuse
of node local memory, even though it had just been pushing allocations
off-node, is a real problem. Anyone care to claim otherwise?
--
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>
next prev parent reply other threads:[~2006-10-10 4:51 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 [this message]
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
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=20061009215125.619655b2.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@google.com \
--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