On Wed, Mar 21, 2018 at 12:39:33PM -0500, Christopher Lameter wrote: > One other thought: If you want to improve the behavior for large scale > objects allocated through kmalloc/kmemcache then we would certainly be > glad to entertain those ideas. > > F.e. you could optimize the allcations > 2x PAGE_SIZE so that they do not > allocate powers of two pages. It would be relatively easy to make > kmalloc_large round the allocation to the next page size and then allocate > N consecutive pages via alloc_pages_exact() and free the remainder unused > pages or some such thing. I don't know if that's a good idea. That will contribute to fragmentation if the allocation is held onto for a short-to-medium length of time. If the allocation is for a very long period of time then those pages would have been unavailable anyway, but if the user of the tail pages holds them beyond the lifetime of the large allocation, then this is probably a bad tradeoff to make. I do see Mikulas' use case as interesting, I just don't know whether it's worth changing slab/slub to support it. At first blush, other than the sheer size of the allocations, it's a good fit. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
