Messages in this thread | | | Date | Sat, 24 Feb 2007 09:32:49 -0800 (PST) | From | Christoph Lameter <> | Subject | Re: SLUB: The unqueued Slab allocator |
| |
On Fri, 23 Feb 2007, David Miller wrote:
> > 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.
Ok. Its currently a compile time option. Will make it possible to specify a boot option.
> I also agree with Andi in that merging could mess up how object type > local lifetimes help reduce fragmentation in object pools.
If that is a problem for particular object pools then we may be able to except those from the merging.
- 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/
| |