Re: [PATCH next/mmotm] slub: partly fix freeze in __slab_free

[Christoph Lameter]

On Wed, 13 Jul 2011, Hugh Dickins wrote:

> As I reported in Fengguang's more_io thread, I couldn't get this patch
> to apply, unsurprisingly to mmotm, more surprisingly to Pekka's for-next
> (which adds in the _count build fix).  Did you try to tidy up the
> indentations a little in between?

Nope. There are multiple patches that fix up thing in mm_types now and
they need to be stacked. I will try to avoid that.

> At the bottom I've put the patch against mmotm which I started testing
> instead on ppc64 a few hours ago.  It again seized up in __slab_free()
> after two and a half hours.  So either I screwed up my transliteration
> of your patch, or your patch is still wrong.  Please check mine out.
>
> Is yours actually tested on PowerPC or ARM, say?  I wonder if you're
> making endianness or bitfield ordering assumptions; but I've made no
> attempt to work it out.  Anything I can send you?  Disassembly of
> __slab_free()?

No I dont have PowerPC or ARM here. The problem is that without the
cmpxchg_double we fall back to slab_lock/slab_unlock. That code is not
that well tested. It is also used for slub_debug and that is how I tested
it.

The patch looks fine. I suspect that the reason lies elsewhere.

__slab_free does not disable interrupts. The use of cmpxchg_double_slab
would have to disable them if it falls back to the pagelock. Sigh.



--
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/