Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

mm, vmscan: unlock page while waiting on writeback

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>

authored by

Hugh Dickins and committed by
Linus Torvalds
7fadc820 26f5d760

+5 -2
+5 -2
mm/vmscan.c
··· 985 985 * __GFP_IO|__GFP_FS for this reason); but more thought 986 986 * would probably show more reasons. 987 987 * 988 - * 3) Legacy memcg encounters a page that is not already marked 988 + * 3) Legacy memcg encounters a page that is already marked 989 989 * PageReclaim. memcg does not have any dirty pages 990 990 * throttling so we could easily OOM just because too many 991 991 * pages are in writeback and there is nothing else to ··· 1015 1015 */ 1016 1016 SetPageReclaim(page); 1017 1017 nr_writeback++; 1018 - 1019 1018 goto keep_locked; 1020 1019 1021 1020 /* Case 3 above */ 1022 1021 } else { 1022 + unlock_page(page); 1023 1023 wait_on_page_writeback(page); 1024 + /* then go back and try same page again */ 1025 + list_add_tail(&page->lru, page_list); 1026 + continue; 1024 1027 } 1025 1028 } 1026 1029