From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org, Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 2/2] mm: do not loop over ALLOC_NO_WATERMARKS without triggering reclaim
Date: Tue, 17 Nov 2015 19:58:09 +0900 [thread overview]
Message-ID: <564B0841.6030409@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <1447680139-16484-3-git-send-email-mhocko@kernel.org>
Michal Hocko wrote:
> __alloc_pages_slowpath is looping over ALLOC_NO_WATERMARKS requests if
> __GFP_NOFAIL is requested. This is fragile because we are basically
> relying on somebody else to make the reclaim (be it the direct reclaim
> or OOM killer) for us. The caller might be holding resources (e.g.
> locks) which block other other reclaimers from making any progress for
> example. Remove the retry loop and rely on __alloc_pages_slowpath to
> invoke all allowed reclaim steps and retry logic.
This implies invoking OOM killer, doesn't it?
> /* Avoid recursion of direct reclaim */
> - if (current->flags & PF_MEMALLOC)
> + if (current->flags & PF_MEMALLOC) {
> + /*
> + * __GFP_NOFAIL request from this context is rather bizarre
> + * because we cannot reclaim anything and only can loop waiting
> + * for somebody to do a work for us.
> + */
> + if (WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
> + cond_resched();
> + goto retry;
I think that this "goto retry;" omits call to out_of_memory() which is allowed
for __GFP_NOFAIL allocations. Even if this is what you meant, current thread
can be a workqueue, which currently need a short sleep (as with
wait_iff_congested() changes), can't it?
> + }
> goto nopage;
> + }
>
> /* Avoid allocations with no watermarks from looping endlessly */
> if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
>
Well, is it cond_resched() which should include
if (current->flags & PF_WQ_WORKER)
schedule_timeout(1);
than wait_iff_congested() because not all yield calls use wait_iff_congested()
and giving pending workqueue jobs a chance to be processed is anyway preferable?
int __sched _cond_resched(void)
{
if (should_resched(0)) {
if ((current->flags & PF_WQ_WORKER) && workqueue_has_pending_jobs())
schedule_timeout(1);
else
preempt_schedule_common();
return 1;
}
return 0;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-11-17 10:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 13:22 [PATCH 0/2] get rid of __alloc_pages_high_priority mhocko
2015-11-16 13:22 ` [PATCH 1/2] mm: " mhocko
2015-11-16 18:43 ` Mel Gorman
2015-11-16 21:14 ` David Rientjes
2015-11-18 14:48 ` Vlastimil Babka
2015-11-16 13:22 ` [PATCH 2/2] mm: do not loop over ALLOC_NO_WATERMARKS without triggering reclaim mhocko
2015-11-16 21:18 ` David Rientjes
2015-11-17 10:58 ` Tetsuo Handa [this message]
2015-11-18 9:11 ` Michal Hocko
2015-11-18 9:22 ` Michal Hocko
2015-11-18 14:57 ` Vlastimil Babka
2015-11-18 15:11 ` Michal Hocko
2015-11-18 15:19 ` Vlastimil Babka
2015-11-23 9:33 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564B0841.6030409@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox