On Fri, 28 Sep 2012, Christoph Lameter wrote: > > No, it's implementation defined so it shouldn't be in kmem_cache_create(), > > it should be in __kmem_cache_create() > > The flags are standardized between allocators. We carve out a couple of > bits here that can be slab specific. > That's true today, it won't be true in a week. > > I'm referring to additional slab allocators that will be proposed for > > inclusion shortly. > > I am sorry but we cannot consider something that has not been discussed > and publicly reviewed on the mailing list before. We have no way to > understand your rationales at this point and it would take quite some time > to review a new allocator. I would at least have expected the design of > the allocator to be discussed on linux-mm. Nothing of that nature has > happened as far as I can tell. > Nobody here is disagreeing that the patch here is fine for slab, slub, and slob as they are currently implemented. I'm simply trying to avoid ripping it out later and asking Glauber to consider something else that achieves what he needs. There is, until this patch, no requirement anywhere that the flags passed to kmem_cache_create() may not be extended for allocator-specific behavior and I'd prefer to avoid adding such a specification unless absolutely necessary; in this case, there is an alternative that I've already outlined and it seems like Glauber is comfortable with using. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>