On Wed, Mar 04, 2015 at 05:52:42PM +1100, Dave Chinner wrote: > I suspect you've completely misunderstood what I've been suggesting. > > By definition, we have the pages we reserved in the reserve pool, > and unless we've exhausted that reservation with permanent > allocations we should always be able to allocate from it. If the > pool got emptied by demand page allocations, then we back off and > retry reclaim until the reclaimable objects are released back into > the reserve pool. i.e. reclaim fills reserve pools first, then when > they are full pages can go back on free lists for normal > allocations. This provides the mechanism for forwards progress, and > it's essentially the same mechanism that mempools use to guarantee > forwards progess. the only difference is that reserve pool refilling > comes through reclaim via shrinker invocation... Yes, I had something else in mind. In order to rely on replenishing through reclaim, you have to make sure that all allocations taken out of the pool are guaranteed to come back in a reasonable time frame. So once Ted said that the filesystem will not be able to declare which allocations of a task are allowed to dip into its reserves, and thus allocations of indefinite lifetime can enter the picture, my mind went to a one-off reserve pool that doesn't rely on replenishing in order to make forward progress. You declare the worst-case, finish the transaction, and return what is left of the reserves. This obviously conflicts with the estimation model that you are proposing, I hope it's now clear where our misunderstanding lies. Yes, we can make this work if you can tell us which allocations have limited/controllable lifetime. -- 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>