On Fri, Feb 27, 2015 at 07:24:34PM +0100, Vlastimil Babka wrote: > On 02/23/2015 08:32 AM, Dave Chinner wrote: > >> > And then there will be an unknown number of > >> > slab allocations of unknown size with unknown slabs-per-page rules > >> > - how many pages needed for them? > > However many pages needed to allocate the number of objects we'll > > consume from the slab. > > I think the best way is if slab could also learn to provide reserves for > individual objects. Either just mark internally how many of them are reserved, > if sufficient number is free, or translate this to the page allocator reserves, > as slab knows which order it uses for the given objects. Which is effectively what a slab based mempool is. Mempools don't guarantee a reserve is available once it's been resized, however, and we'd have to have mempools configured for every type of allocation we are going to do. So from that perspective it's not really a solution. Further, the kmalloc heap is backed by slab caches. We do *lots* of variable sized kmalloc allocations in transactions the size of which aren't known until allocation time. In that case, we have to assume it's going to be a page per object, because the allocations could actually be that size. AFAICT, the worst case is a slab-backing page allocation for every slab object that is allocated, so we may as well cater for that case from the start... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
