From: Johannes Weiner <hannes@cmpxchg.org>
To: yang.yang29@zte.com.cn
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, iamjoonsoo.kim@lge.com, willy@infradead.org
Subject: Re: [PATCH linux-next] mm: workingset: simplify the calculation of workingset size
Date: Thu, 16 Mar 2023 10:30:07 -0400 [thread overview]
Message-ID: <20230316143007.GC116016@cmpxchg.org> (raw)
In-Reply-To: <202303161723055514455@zte.com.cn>
On Thu, Mar 16, 2023 at 05:23:05PM +0800, yang.yang29@zte.com.cn wrote:
> From: Yang Yang <yang.yang29@zte.com.cn>
>
> After we implemented workingset detection for anonymous LRU[1],
> the calculation of workingset size is a little complex. Actually there is
> no need to call mem_cgroup_get_nr_swap_pages() if refault page is
> anonymous page, since we are doing swapping then should always
> give pressure to NR_ACTIVE_ANON.
This is false.
(mem_cgroup_)get_nr_swap_pages() returns the *free swap slots*. There
might be swap, but if it's full, reclaim stops scanning anonymous
pages altogether. That means that refaults of either type can no
longer displace existing anonymous pages, only cache.
So yes, all refaults need to check free swap to determine how to act
on the reuse frequency.
> @@ -466,22 +466,23 @@ void workingset_refault(struct folio *folio, void *shadow)
> /*
> * Compare the distance to the existing workingset size. We
> * don't activate pages that couldn't stay resident even if
> - * all the memory was available to the workingset. Whether
> - * workingset competition needs to consider anon or not depends
> - * on having swap.
> + * all the memory was available to the workingset. For page
> + * cache whether workingset competition needs to consider
> + * anon or not depends on having swap.
No, it applies to all refaults, not just cache.
What could help is changing the comment to "having free swap space".
next prev parent reply other threads:[~2023-03-16 14:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 9:23 yang.yang29
2023-03-16 13:14 ` Matthew Wilcox
2023-03-16 14:30 ` Johannes Weiner [this message]
[not found] ` <20230317015903.16978-1-yang.yang29@zte.com.cn>
2023-03-17 14:09 ` Johannes Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230316143007.GC116016@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
--cc=yang.yang29@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox