slub: Remove slub_nomerge

No one has used that option for a long time and AFAICT its currently utterly useless.

Signed-off-by Christoph Lameter <[email protected]>

No one has used that option for a long time and AFAICT its currently utterly useless.

And when studying slabinfo numbers, perhaps for a leak e.g. why doesn't slabinfo doesn't show vm_area_struct, oh, it's sharing :0000088 with cfq_queue, so we need slub_nomerge to see their actual numbers. Perhaps I'm missing something: how does everyone else get the right numbers without slub_nomerge?

Admittedly it's often too blunt an instrument for debugging: I'd be happier with a debug flag which has no other side-effect than nomerge (all the other SLUB_NEVER_MERGE flags seemed to have side-effects that I wanted to avoid when trying to reproduce an elusive corruption), that can be applied to a single cache as well as to the whole lot.

I could add that if you don't (or I could hack my mm/slub.c when I need to, that's always an option: but I do think nomerge can be useful out in the field). If you go ahead and remove slub_nomerge, please also remove it from Documentation/kernel-parameters.txt.

Group SLUB_DEBUG code together to reduce the number of #ifdefs.

Signed-off-by Christoph Lameter <[email protected]>

Quoted 3 lines · Christoph Lameter

Group SLUB_DEBUG code together to reduce the number of #ifdefs.

Signed-off-by Christoph Lameter <[email protected]>

This doesn't just rearrange #ifdefs, it moves the poisoning checks under #ifdef too (which is safe). You might want to mention that in the changelogs.

No need to access the kmem_cache structure. We have the same value in kmem_cache_cpu.

Signed-off-by Christoph Lameter <[email protected]>

The BUG_ONs are useless since the pointer derefs will lead to NULL deref errors anyways. Some of the checks are not necessary if no debugging is possible.

Signed-off-by Christoph Lameter <[email protected]>

(quoted diff) +1 -0

+#ifdef CONFIG_SLUB_DEBUG
 	/*
 	 * Debugging requires use of the padding between object
 	 * and whatever may come after it.

Why are you wrapping the SLAB_DESTORY_BY_RCU case with CONFIG_SLUB_DEBUG too?

Quoted 1 line

Why are you wrapping the SLAB_DESTORY_BY_RCU case with CONFIG_SLUB_DEBUG too?

Mistake on my part. Corrected patch follows:

From 74d3c465f217f3103e7a6d21cb090497386de8be Mon Sep 17 00:00:00 2001
From: Christoph Lameter <[email protected]>
Date: Fri, 15 Feb 2008 23:45:25 -0800
Subject: [PATCH] slub: Remove BUG_ON() from ksize and omit checks for !SLUB_DEBUG

The BUG_ONs are useless since the pointer derefs will lead to NULL deref errors anyways. Some of the checks are not necessary if no debugging is possible.

Signed-off-by Christoph Lameter <[email protected]>

Slub is missing some NUMA support for large kmallocs. Provide that.

Signed-off-by Christoph Lameter <[email protected]>

Alloc debug processing is never called with a NULL object pointer. No reason to check for NULL.

Signed-off-by Christoph Lameter <[email protected]>

There is no page->offset anymore and also no associated limit on the number of objects. The page->offset field was removed for 2.6.24. So the check in kmem_cache_flags() is now also obsolete (should have been dropped earlier, somehow a hunk vanished).

Signed-by Christoph Lameter <[email protected]>

This only made sense for the alternate fastpath which was reverted last week.

Mathieu is working on a new version that addresses the fastpath issues but that new code first needs to go through mm and it is not clear if we need the unique end pointers with his new scheme.

Signed-off-by Christoph Lameter <[email protected]>