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. >> > And to make it much worse, how >> > many pages of which orders? Bless its heart, slub will go and use >> > a 1-order page for allocations which should have been in 0-order >> > pages.. > The majority of allocations will be order-0, though if we know that > they are going to be significant numbers of high order allocations, > then it should be simple enough to tell the mm subsystem "need a > reserve of 32 order-0, 4 order-1 and 1 order-3 allocations" and have > memory compaction just do it's stuff. But, IMO, we should cross that > bridge when somebody actually needs reservations to be that > specific.... Note that watermark checking for higher-order allocations is somewhat fuzzy compared to order-0 checks, but I guess some kind of reservations could work there too. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
