GFP_NOFAIL cleanups
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 20 repliesIn review 2 of 3 applied
Patches in v1 2 of 3 applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | mm: consolidate GFP_NOFAIL checks in the allocator slowpathmm/ | +44 | 0 replies | Applied |
| 2/3 | mm, oom: do not enfore OOM killer for __GFP_NOFAIL automaticallymm/ mm/ | +25 | 9 replies | |
| 3/3 | mm: help __GFP_NOFAIL allocations which do not trigger OOM killermm/ | +36 | 0 replies | Applied |
Reviews trailers per patch
2 of 3 patches have a Reviewed-by or Acked-by.
| Patch | Vlastimil Babka | Johannes Weiner | Hillf Danton |
|---|---|---|---|
| 1/3 | A-b | A-b | A-b |
| 2/3 | A-b | ||
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 3 reviewers.
Cover letter [PATCH 0/3 -v3] GFP_NOFAIL cleanups
Hi,
This has been posted [1] initially to later be reduced to a single patch [2]. Johannes then suggested [3] to split up the second patch and make the access to memory reserves by __GF_NOFAIL requests which do not invoke the oom killer a separate change. This is patch 3 now.
Tetsuo has noticed [4] that recent changes have changed GFP_NOFAIL semantic for costly order requests. I believe that the primary reason why this happened is that our GFP_NOFAIL checks are too scattered and it is really easy to forget about adding one. That's why I am proposing patch 1 which consolidates all the nofail handling at a single place. This should help to make this code better maintainable.
Patch 2 on top is a further attempt to make GFP_NOFAIL semantic less surprising. As things stand currently GFP_NOFAIL overrides the oom killer prevention code which is both subtle and not really needed. The patch 2 has more details about issues this might cause. We have also seen a report where __GFP_NOFAIL|GFP_NOFS requests cause the oom killer which is premature.
Patch 3 is an attempt to reduce chances of GFP_NOFAIL requests being preempted by other memory consumers by giving them access to memory reserves.
[1] http://lkml.kernel.org/r/[email protected]
[2] http://lkml.kernel.org/r/[email protected]
[3] http://lkml.kernel.org/r/[email protected]
[4] http://lkml.kernel.org/r/1479387004-5998-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>