lkml.org 
[lkml]   [2020]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v16 00/22] per memcg lru_lock
On Mon, 20 Jul 2020, Alex Shi wrote:
> 在 2020/7/19 下午11:23, Hugh Dickins 写道:
> > 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 <hughd@google.com>
>
> 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).

>
> 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))) {
\
 
 \ /
  Last update: 2020-07-20 06:48    [W:0.081 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site