Messages in this thread | | | Date | Wed, 13 Jul 2011 10:47:11 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: [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 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.
| |