On Wed, 11 Sep 2019 19:07:34 +0900 > > But I guess that there is a problem. Not a new one. (see commit 7dea19f9ee63) > Setting PF_MEMALLOC_NOIO causes > current_gfp_context() to mask __GFP_IO | __GFP_FS, but the OOM killer cannot > be invoked when __GFP_FS is masked. As a result, any userspace thread which > has PF_MEMALLOC_NOIO cannot invoke the OOM killer. Correct. > If the userspace thread > which uses PF_MEMALLOC_NOIO is involved in memory reclaiming activities, > the memory reclaiming activities won't be able to make forward progress when > the userspace thread triggered e.g. a page fault. Can the "userspace components > that can run in the IO path" survive without any memory allocation? Good question. It can be solved without oom killer involved because user should be aware of the risk of PF_MEMALLOC_NOIO if they ask for the convenience. OTOH we are able to control any abuse of it as you worry, knowing that the combination of __GFP_FS and oom killer can not get more than 50 users works done, and we have to pay as much attention as we can to the decisions they make. In case of PF_MEMALLOC_NOIO, we simply fail the allocation rather than killing a random victim. --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3854,6 +3854,8 @@ __alloc_pages_may_oom(gfp_t gfp_mask, un * out_of_memory). Once filesystems are ready to handle allocation * failures more gracefully we should just bail out here. */ + if (current->flags & PF_MEMALLOC_NOIO) + goto out; /* The OOM killer may not free memory on a specific node */ if (gfp_mask & __GFP_THISNODE)
