linux-kernel - Re: [PATCH] Move memory controller allocations to their own slabs (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47D6D3CC.5070705@linux.vnet.ibm.com>
Date:	Wed, 12 Mar 2008 00:17:40 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Hugh Dickins <hugh@...itas.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelianov <xemul@...nvz.org>,
	Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
	Paul Menage <menage@...gle.com>, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org, taka@...inux.co.jp,
	linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH] Move memory controller allocations to their own slabs
 (v2)

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
>> page_cgroup's.
>>
>> Signed-off-by: Balbir Singh <balbir@...ux.vnet.ibm.com>
> 
> 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.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/