Re: [PATCH v16 00/22] per memcg lru_lock
From: Hugh Dickins <hidden>
Date: 2020-07-20 04:48:12
Also in:
linux-mm, lkml
On Mon, 20 Jul 2020, Alex Shi wrote:
在 2020/7/19 下午11:23, Hugh Dickins 写道:quoted
I noticed that 5.8-rc5, with lrulock v16 applied, took significantly longer to run loads than without it applied, when there should have been only slight differences in system time. Comparing /proc/vmstat, something that stood out was "pgrotated 0" for the patched kernels, which led here: If pagevec_lru_move_fn() is now to TestClearPageLRU (I have still not decided whether that's good or not, but assume here that it is good), then functions called though it must be changed not to expect PageLRU! Signed-off-by: Hugh Dickins <redacted>Good catch! Thanks a lot, Hugh! except 6 changes should apply, looks we add one more in swap.c file to stop !PageRLU further actions!
Agreed, that's a minor optimization that wasn't done before, that can be added (but it's not a fix like the rest of them).
quoted hunk ↗ jump to hunk
Many Thanks! Alex@@ -649,7 +647,7 @@ void deactivate_file_page(struct page *page) * In a workload with many unevictable page such as mprotect, * unevictable page deactivation for accelerating reclaim is pointless. */ - if (PageUnevictable(page)) + if (PageUnevictable(page) || !PageLRU(page)) return; if (likely(get_page_unless_zero(page))) {