mm, vmscan: unlock page while waiting on writeback (7fadc820) · Commits · 戴 / test

This is merely a politeness: I've not found that shrink_page_list() leads to deadlock with the page it holds locked across wait_on_page_writeback(); but nevertheless, why hold others off by keeping the page locked there? And while we're at it: remove the mistaken "not " from the commentary on this Case 3 (and a distracting blank line from Case 2, if I may). Signed-off-by:

Hugh Dickins <hughd@google.com> Acked-by:

Michal Hocko <mhocko@suse.com> Acked-by:

Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@techsingularity.net> Signed-off-by:

Andrew Morton <akpm@linux-foundation.org> Signed-off-by:

Linus Torvalds <torvalds@linux-foundation.org>

mm/vmscan.c

+5 −2

Original line number	Diff line number	Diff line
		@@ -985,7 +985,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
		* __GFP_IO\|__GFP_FS for this reason); but more thought
		* would probably show more reasons.
		*
		* 3) Legacy memcg encounters a page that is not already marked
		* 3) Legacy memcg encounters a page that is already marked
		* PageReclaim. memcg does not have any dirty pages
		* throttling so we could easily OOM just because too many
		* pages are in writeback and there is nothing else to
		@@ -1015,12 +1015,15 @@ static unsigned long shrink_page_list(struct list_head *page_list,
		*/
		SetPageReclaim(page);
		nr_writeback++;

		goto keep_locked;

		/* Case 3 above */
		} else {
		unlock_page(page);
		wait_on_page_writeback(page);
		/* then go back and try same page again */
		list_add_tail(&page->lru, page_list);
		continue;
		}
		}

Admin message