On 11/22/18 9:23 AM, Christoph Hellwig wrote: > On Wed, Nov 21, 2018 at 10:26:26PM +0000, Robin Murphy wrote: >> TBH, if this DMA32 stuff is going to be contentious we could possibly just >> rip out the offending kmem_cache - it seemed like good practice for the >> use-case, but provided kzalloc(SZ_1K, gfp | GFP_DMA32) can be relied upon to >> give the same 1KB alignment and chance of succeeding as the equivalent >> kmem_cache_alloc(), then we could quite easily make do with that instead. > > Neither is the slab support for kmalloc, not do kmalloc allocations > have useful alignment apparently (at least if you use slub debug). Is this also true for caches created by kmem_cache_create(), that debugging options can result in not respecting the alignment passed to kmem_cache_create()? That would be rather bad, IMHO. > But I do agree with the sentiment of not wanting to spread GFP_DMA32 > futher into the slab allocator. I don't see a problem with GFP_DMA32 for custom caches. Generic kmalloc() would be worse, since it would have to create a new array of kmalloc caches. But that's already ruled out due to the alignment. > I think you want a simple genalloc allocator for this rather special > use case. I would prefer if slab could support it, as it doesn't have to preallocate. OTOH if the allocations are GFP_ATOMIC as suggested later in the thread, and need to always succeed, then preallocation could be better, and thus maybe genalloc.
