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: Tue, 26 Oct 2010 08:10:23 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1010260804080.813@router.home> (raw)
In-Reply-To: <20101026111025.B7B2.A69D9226@jp.fujitsu.com>
On Tue, 26 Oct 2010, KOSAKI Motohiro wrote:
> But, I have one question. Do you want to keep per-cpu cache although
> reclaim running? If my remember is correct, your unified slab allocator
> patch series drop percpu slab cache if memory reclaim occur.
I modified the unified allocator to use a slab shrinker for the next
release.
> I mean I'd like to know how much important slab percpu cache is. can
> you please explain your ideal cache dropping behavior of slab?
Caches both keep state of the physical cpu caches and optimize locking
since you avoid the overhead of taking objects from slab pages and pushing
them in. Ideally they are kept as long as possible. But if the system has
other needs then they should be dropped so that pages can be freed.
> > 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.
>
> IOMMU is certenary modern. but it's still costly a bit. So I'm not sure
> all desktop devices will equip IOMMU. At least, we still have 32bit limitation
> drivers in kernel tree. At least, desktop pc of this year still have PCI slot.
>
> Another interesting example, KVM is one of user __GFP_DMA32. it is
> necessary to implement 32bit cpu emulation (i.e. 32bit guest).
Why does KVM use __GFP_DMA32? They need a physical address below 32 bit in
the 64 bit host? A 32 bit guest would only have __GFP dma and not
GFP_DMA32.
> I'm not sure destroying zone is good idea. I can only say that it still has
> user even nowaday..
Sure it does but it creates certain headaches. I like those to be reduced
as much as possible.
> So again, I was thinking a reclaim should drop both page allocator pcp
> cache and slab cpu cache. Am I wrong? if so, why do you disagree?
I agree.
--
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>
prev parent reply other threads:[~2010-10-26 13:10 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
2010-10-26 2:52 ` KOSAKI Motohiro
2010-10-26 12:42 ` KOSAKI Motohiro
2010-10-26 13:10 ` Christoph Lameter [this message]
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.1010260804080.813@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).