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

Context information in memory-allocation requests

Posted Jan 5, 2017 18:09 UTC (Thu) by rghetta (subscriber, #39444)
Parent article: Context information in memory-allocation requests

speaking from personal experience, the downside of having a flag handled the proposed way is making much more difficult future changes to GPF_NOFS behaviour. The current approach, cumbersome as it is, makes all uses of GPF_NOFS explicit, so one can know if a particular allocation has the flag set or not. With an external flag, this is much more difficult to determine, because one needs to look not only at all the call chains leading to the allocation, but also at all the possible histories of the thread.

to post comments

Context information in memory-allocation requests

Posted Jan 5, 2017 22:51 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> With an external flag, this is much more difficult to determine, because one needs to look not only at all the call chains leading to the allocation, but also at all the possible histories of the thread.

In principle all the functions that set the flag should also clear it before returning, so the thread flag follows the same "dynamic scope" as the current flag arguments. The history of the thread should not be a factor, apart from the call stack. Of course it's possible to get this protocol wrong, but provided the flag is used as intended I don't see how checking for a GPF_NOFS argument and following the call tree down to the allocation site is simpler or easier than checking for and similarly tracing any calls which occur between memalloc_nofs_save() and memalloc_nofs_restore().

Context information in memory-allocation requests

Posted Jan 6, 2017 11:27 UTC (Fri) by smurf (subscriber, #17840) [Link]

Actually, in principle there's no difference between passing the flag up the call chain or setting it in the task struct – you need to check all caller chains in both cases.

The advantages of a per-task flag are that (a) you don't need the stupid function parameter everywhere, resulting in a (very small) speed-up and somewhat more readable code, and (b) you don't miss calls where it'd be reqired.