From: Christoph Lameter <cl@linux.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: akpm@linux-foundation.org, npiggin@kernel.dk,
Pekka Enberg <penberg@cs.helsinki.fi>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: vmscan: Do not run shrinkers for zones other than ZONE_NORMAL
Date: Mon, 25 Oct 2010 10:07:59 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1010251000480.7461@router.home> (raw)
In-Reply-To: <20101025101009.915D.A69D9226@jp.fujitsu.com>
On Mon, 25 Oct 2010, KOSAKI Motohiro wrote:
> > The per zone approach seems to be at variance with how objects are tracked
> > at the slab layer. There is no per zone accounting there. So attempts to
> > do expiration of caches etc at that layer would not work right.
>
> Please define your 'right' behavior ;-)
Right here meant not excessive shrink calls for a particular node.
> If we need to discuss 'right' thing, we also need to define how behavior
> is right, I think. slab API itself don't have zone taste. but it implictly
> depend on a zone because buddy and reclaim are constructed on zones and
> slab is constructed on buddy. IOW, every slab object have a home zone.
True every page has a zone. However, per cpu caching and NUMA distances
only work per node (or per cache sharing domain which may just be a
fraction of a "node"). The slab allocators attempt to keep objects on
queues that are cache hot. For that purpose only the node matters not the
zone.
> So, which workload or usecause make a your head pain?
The head pain is because of the conflict of object tracking in the page
allocator per zone and in the slabs per node.
In general per zone object tracking in the page allocators percpu lists is
not optimal since at variance with how the cpu caches actually work.
- Cpu caches exist typically per node or per sharing domain (which is not
reflected in the page allocators at all)
- NUMA distance effects only change for per node allocations.
The concept of a "zone" is for the benefit of certain legacy drivers that
have limitations for the memory range on which they can performa DMA
operations. With the IOMMUs and other modern technology this should no
longer be an issue.
An Mel used it to attach a side car (ZONE_MOVABLE) to the VM ...
--
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:[~2010-10-25 15:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 17:59 vmscan: Do not run shrinkers for zones other than ZONE_NORMAL Christoph Lameter
2010-10-21 18:00 ` shrinkers: Add node to indicate where to target shrinking Christoph Lameter
2010-10-21 18:12 ` Andi Kleen
2010-10-21 20:57 ` David Rientjes
2010-10-21 21:07 ` Christoph Lameter
2010-10-22 13:27 ` Andi Kleen
2010-10-21 23:58 ` Nick Piggin
2010-10-22 12:12 ` Andi Kleen
2010-10-22 15:55 ` Christoph Hellwig
2010-10-22 16:32 ` Christoph Lameter
2010-10-24 1:42 ` Nick Piggin
2010-10-25 0:57 ` KOSAKI Motohiro
2010-10-25 14:59 ` Christoph Lameter
2010-11-09 4:03 ` Nick Piggin
2010-10-22 16:46 ` Andi Kleen
2010-10-24 1:31 ` Nick Piggin
2010-11-14 2:26 ` Michel Lespinasse
2010-11-14 7:10 ` KOSAKI Motohiro
2010-11-14 11:05 ` Michel Lespinasse
2010-11-15 0:29 ` KOSAKI Motohiro
2010-10-21 18:13 ` vmscan: Do not run shrinkers for zones other than ZONE_NORMAL Andi Kleen
2010-10-21 18:22 ` Christoph Lameter
2010-10-21 18:27 ` Christoph Lameter
2010-10-21 18:33 ` Andi Kleen
2010-10-21 20:48 ` David Rientjes
2010-10-21 20:54 ` Christoph Lameter
2010-10-21 19:40 ` Andrew Morton
2010-10-21 20:03 ` Christoph Lameter
2010-10-21 20:14 ` Andrew Morton
2010-10-21 20:28 ` Christoph Lameter
2010-10-21 20:36 ` Andrew Morton
2010-10-21 20:49 ` Christoph Lameter
2010-10-21 20:59 ` Andrew Morton
2010-10-21 21:13 ` Christoph Lameter
2010-10-21 21:21 ` Andrew Morton
2010-10-21 23:04 ` Christoph Lameter
2010-10-21 23:56 ` Nick Piggin
2010-10-22 1:37 ` KOSAKI Motohiro
2010-10-22 14:06 ` Christoph Lameter
2010-10-24 1:37 ` Nick Piggin
2010-10-25 1:22 ` KOSAKI Motohiro
2010-10-25 15:07 ` Christoph Lameter [this message]
2010-10-26 2:52 ` KOSAKI Motohiro
2010-10-26 12:42 ` KOSAKI Motohiro
2010-10-26 13:10 ` 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=alpine.DEB.2.00.1010251000480.7461@router.home \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=npiggin@kernel.dk \
--cc=penberg@cs.helsinki.fi \
--cc=rientjes@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;
as well as URLs for NNTP newsgroup(s).