Messages in this thread | | | Date | Fri, 23 Feb 2007 21:54:39 -0800 (PST) | Subject | Re: SLUB: The unqueued Slab allocator | From | David Miller <> |
| |
From: Christoph Lameter <clameter@engr.sgi.com> Date: Fri, 23 Feb 2007 21:47:36 -0800 (PST)
> On Sat, 24 Feb 2007, KAMEZAWA Hiroyuki wrote: > > > >From a viewpoint of a crash dump user, this merging will make crash dump > > investigation very very very difficult. > > The general caches already merge lots of users depending on their sizes. > So we already have the situation and we have tools to deal with it.
But this doesn't happen for things like biovecs, and that will make debugging painful.
If a crash happens because of a corrupted biovec-256 I want to know it was a biovec not some anonymous clone of kmalloc256.
Please provide at a minimum a way to turn the merging off.
I also agree with Andi in that merging could mess up how object type local lifetimes help reduce fragmentation in object pools.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |