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>
This commit is contained in:
Родитель
26f5d7609f
Коммит
7fadc82022
|
@ -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;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
Загрузка…
Ссылка в новой задаче