RFC GFP_NOFAIL cleanups
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 patches 9 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | mm: consolidate GFP_NOFAIL checks in the allocator slowpathmm/ | +41 | 1 reply | |
| 2/2 | mm, oom: do not enfore OOM killer for __GFP_NOFAIL automaticallymm/ mm/ | +59 | 8 replies |
Reviews trailers per patch
1 of 2 patches has a Reviewed-by or Acked-by.
| Patch | Vlastimil Babka |
|---|---|
| 1/2 | A-b |
| 2/2 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC 0/2] GFP_NOFAIL cleanups
Hi,
Tetsuo has noticed [1] 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.
I would consider both patches more a cleanup than anything else. Any feedback is highly appreciated.
[1] 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>