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

[Balbir Singh]

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@xxxxxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/