From: zhong jiang <zhongjiang-ali@linux.alibaba.com>
To: Michal Hocko <mhocko@suse.com>
Cc: hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: Do not deactivate when the cgroup has plenty inactive page
Date: Sun, 27 Sep 2020 10:39:22 +0800 [thread overview]
Message-ID: <cdf5dbf6-2f29-b9f3-60df-8242921e1bae@linux.alibaba.com> (raw)
In-Reply-To: <20200925120758.GF3389@dhcp22.suse.cz>
On 2020/9/25 8:07 下午, Michal Hocko wrote:
> On Fri 25-09-20 19:49:12, zhongjiang-ali wrote:
>> After appling the series patches(mm: fix page aging across multiple cgroups),
>> cgroup memory reclaim strategy is based on reclaim root's inactive:active
>> ratio. if the target lruvec need to deactivate, its children cgroup also will
>> deactivate. That will result in hot page to be reclaimed and other cgroup's
>> cold page will be left, which is not expected.
>>
>> The patch will not force deactivate when inactive_is_low is not true unless
>> we has scanned the inactive list and memory is unable to reclaim.
> Do you have any data to present?
I write an testcase that cgroup B has a lot of hot pagecache and cgroup
C is full of cold pagecache. and
their parent cgroup A will trigger the reclaim due of it's limit has
been breached.
The testcase should assume that we should not reclaim the hot pagecache
in cgroup B because C has
plenty cold pagecache. Unfortunately, I can see cgroup B hot
pagecache has been decreased when
cgroup A trigger the reclaim.
Thanks,
>
>> Signed-off-by: zhongjiang-ali <zhongjiang-ali@linux.alibaba.com>
>> ---
>> mm/vmscan.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 466fc31..77d395f 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -2407,8 +2407,21 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>> case SCAN_FILE:
>> case SCAN_ANON:
>> /* Scan one type exclusively */
>> - if ((scan_balance == SCAN_FILE) != file)
>> + if ((scan_balance == SCAN_FILE) != file) {
>> scan = 0;
>> + } else {
>> + /*
>> + * Reclaim memory is based on the root's inactive: active
>> + * ratio, but it is possible that silbing cgroup has a lot
>> + * of cold memory to reclaim rather than reclaim the hot
>> + * cache in the current cgroup.
>> + */
>> + if (!sc->force_deactivate && is_active_lru(lru) &&
>> + !inactive_is_low(lruvec, lru - LRU_ACTIVE)) {
>> + if (sc->may_deactivate & (1 << file))
>> + scan = 0;
>> + }
>> + }
>> break;
>> default:
>> /* Look ma, no brain */
>> --
>> 1.8.3.1
>>
next prev parent reply other threads:[~2020-09-27 2:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 11:49 [PATCH] mm: Do not deactivate when the cgroup has plenty inactive page zhongjiang-ali
2020-09-25 12:07 ` Michal Hocko
2020-09-27 2:39 ` zhong jiang [this message]
2020-09-29 16:02 ` Michal Hocko
2020-10-14 14:21 ` zhong jiang
2020-10-14 14:47 ` Michal Hocko
2020-10-14 16:57 ` zhong jiang
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=cdf5dbf6-2f29-b9f3-60df-8242921e1bae@linux.alibaba.com \
--to=zhongjiang-ali@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/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;
as well as URLs for NNTP newsgroup(s).