Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 7fadc820 authored by Hugh Dickins's avatar Hugh Dickins Committed by Linus Torvalds
Browse files

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: default avatarHugh Dickins <hughd@google.com>
Acked-by: default avatarMichal Hocko <mhocko@suse.com>
Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 26f5d760

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;

			}

		}