From: Yang Yang <yang.yang29@zte.com.cn>
To: hannes@cmpxchg.org
Cc: akpm@linux-foundation.org, iamjoonsoo.kim@lge.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
willy@infradead.org, yang.yang29@zte.com.cn
Subject: Re: [PATCH linux-next] mm: workingset: simplify the calculation of workingset size
Date: Sat, 18 Mar 2023 03:10:04 +0000 [thread overview]
Message-ID: <20230318031004.19012-1-yang.yang29@zte.com.cn> (raw)
In-Reply-To: <20230317140952.GA153257@cmpxchg.org>
> On Fri, Mar 17, 2023 at 01:59:03AM +0000, Yang Yang wrote:
>> I see in this patch "mm: vmscan: enforce inactive:active ratio at the
>> reclaim root", reclaim will be done in the combined workingset of
>> different workloads in different cgroups.
>>
>> So if current cgroup reach it's swap limit(mem_cgroup_get_nr_swap_pages(memcg) == 0),
>> but other cgroup still has swap slot, should we allow the refaulting page
>> to active and give pressure to other cgroup?
>
> That's what we do today.
>
> The shadow entry remembers the reclaim root, so that refaults can
> later evaluated at the same level. So, say you have:
>
> root - A - A1
> `- A2
> and A1 and A2 are reclaimed due to a limit in A. The shadow entries of
> evictions from A1 and A2 will actually refer to A.
>
> When they refault later on, the distance is interpreted based on
> whether A has swap (eviction_lruvec).
Much appreciate to your patient explanation.
Still a question:
In the example above, if (NR_ACTIVE_FILE + NR_INACTIVE_FILE) <
refault_distance < (NR_ACTIVE_FILE + NR_INACTIVE_FILE + NR_ACTIVE_ANON),
and swap slot is full, the refault page is not set active. Then if some
swap slots is freed, the newly refault page might be early reclaimed
since it's inactive.
And if we let the refault page be set active evenif swap slot is full,
when swap slot is freed, the refault page is protected from being early
relcaimed.
prev parent reply other threads:[~2023-03-18 3:10 UTC|newest]
Thread overview: 6+ 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
2023-03-17 1:59 ` Yang Yang
2023-03-17 14:09 ` Johannes Weiner
2023-03-18 3:10 ` Yang Yang [this message]
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=20230318031004.19012-1-yang.yang29@zte.com.cn \
--to=yang.yang29@zte.com.cn \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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
all inboxes | Powered by JetHome®