Context information in memory-allocation requests [LWN.net]

Context information in memory-allocation requests

Posted Jan 5, 2017 12:54 UTC (Thu) by willy (subscriber, #9762)
Parent article: Context information in memory-allocation requests

I've had occasion to think about GFP_NOFS over the last week, and I think there's a simpler solution to removing it. Rather than setting/clearing a per-process flag like Michael's proposal, why not a per-superblock flag? A filesystem would set the SUPER_NO_RECLAIM flag when starting a transaction, and clear it after ending the transaction. Upon entry to the shrinker, check to see if SUPER_NO_RECLAIM is set, and if it is, return SHRINK_STOP.

This seems too obvious for everybody else to have missed, so what's the problem with this?

(It also allows one filesystem to shrink in order to make space for an unrelated filesystem to make progress. And filesystems can migrate to it on an individual basis; no giant flag day)

to post comments

Context information in memory-allocation requests

Posted Jan 5, 2017 15:51 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

Wouldn't that method allow an arbitrarily deep file system call chain?

Context information in memory-allocation requests

Posted Jan 5, 2017 22:40 UTC (Thu) by willy (subscriber, #9762) [Link]

You're right; we need to limit recursion. The current GFP_NOFS is a rather blunt instrument and I think we can do better.

It's reasonable for each shrinker to estimate how much stack it's likely to consume to free memory. If we have a function that returns how much stack is still available, a shrinker can know whether to try to free memory or to fail.