linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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
>>


  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).