LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Balbir Singh <firstname.lastname@example.org>
To: Hugh Dickins <email@example.com>
Cc: Andrew Morton <firstname.lastname@example.org>,
Pavel Emelianov <email@example.com>,
Sudhir Kumar <firstname.lastname@example.org>,
YAMAMOTO Takashi <email@example.com>,
Paul Menage <firstname.lastname@example.org>,
David Rientjes <email@example.com>,
KAMEZAWA Hiroyuki <firstname.lastname@example.org>
Subject: Re: [PATCH] Move memory controller allocations to their own slabs (v2)
Date: Wed, 12 Mar 2008 00:17:40 +0530 [thread overview]
Message-ID: <47D6D3CC.email@example.com> (raw)
Hugh Dickins wrote:
> On Tue, 11 Mar 2008, Balbir Singh wrote:
>> Move the memory controller data structure page_cgroup to its own slab cache.
>> It saves space on the system, allocations are not necessarily pushed to order
>> of 2 and should provide performance benefits. Users who disable the memory
>> controller can also double check that the memory controller is not allocating
>> Signed-off-by: Balbir Singh <firstname.lastname@example.org>
> I certainly approve of giving page_cgroups their own kmem_cache
> (and agree with Kame that it was overkill for the zones).
Thanks, yes, I agreed with Kame as well.
> But I don't agree with the SLAB_HWCACHE_ALIGN you've slipped into
> this version. That'll be wasting a lot of (all? more than?) the
> space you're trying to save with a kmem_cache, won't it? Let me
> talk about that separately, in reply to the mail where you report
> the numbers.
I slipped in the SLAB_HWCACHE_ALIGN to reduce page cgroup cache contention. Yes
you are right, we do lose out on space due to the extra alignment. My test
results (lmbench) on kmalloc, slub and slab are not very conclusive about
performance. SLUB had the best results w.r.t protection faults and context switches.
> Are you proposing this page_cgroup_cache mod for 2.6.25 or for 2.6.26?
I am OK with any version as long as we can get good feedback. I suspect the
feature will be useful for 2.6.25.
> I ask because I want to build upon it to fix up some GFP_ flag issues:
> I think we end up claiming the page_cgroups are __GFP_MOVABLE when they
> should be called __GFP_RECLAIMABLE; but I don't know how seriously we
> take MOVABLE/RECLAIMABLE discrepancies at present.
That's a very good question. I am not sure about the correct answer to that
myself at the moment.
> There's a patch I'd also like to build upon from Christoph in -mm
> (remove-set_migrateflags.patch), which sheds light on a similar issue
> with radix_tree_nodes). It's importance is again dependent on how
> seriously we're taking MOVABLE/RECLAIMABLE discrepancies.
I'll look at Christoph's patch and see what it addresses to understand the
MOVABLE/RECLAIMABLE discrepancy better.
Linux Technology Center
prev parent reply other threads:[~2008-03-11 18:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-11 6:18 Balbir Singh
2008-03-11 8:11 ` Pavel Emelyanov
2008-03-11 8:15 ` Balbir Singh
2008-03-11 8:35 ` Pavel Emelyanov
2008-03-11 11:09 ` Balbir Singh
2008-03-11 13:05 ` Hugh Dickins
2008-03-12 3:38 ` Nick Piggin
2008-03-12 3:48 ` Balbir Singh
2008-03-11 12:55 ` Hugh Dickins
2008-03-11 18:47 ` Balbir Singh [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] Move memory controller allocations to their own slabs (v2)' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).