[lkml]   [2011]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH next/mmotm] slub: partly fix freeze in __slab_free
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

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.

 \ /
  Last update: 2011-07-13 17:49    [W:0.064 / U:5.348 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site