linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Haifeng Xu <haifeng.xu@shopee.com>
Cc: hannes@cmpxchg.org, shakeelb@google.com, muchun.song@linux.dev,
	akpm@linux-foundation.org, cgroups@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/memcg: Skip high limit check in root memcg
Date: Tue, 21 Feb 2023 13:20:40 +0100	[thread overview]
Message-ID: <Y/S3GHT1P6awZaPb@dhcp22.suse.cz> (raw)
In-Reply-To: <82918a12-d83e-10c0-0e04-eec26657b699@shopee.com>

On Tue 21-02-23 18:29:39, Haifeng Xu wrote:
> 
> 
> On 2023/2/14 23:56, Michal Hocko wrote:
> > On Fri 10-02-23 09:45:50, Haifeng Xu wrote:
> >> The high limit checks the memory usage from given memcg to root memcg.
> >> However, there is no limit in root memcg. So this check makes no sense
> >> and we can ignore it.
> > 
> > Is this check actually addining any benefit? Have you measured aby
> > performance gains by this change?
> > 
> >> Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
> >> ---
> >>  mm/memcontrol.c | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >> index 73afff8062f9..a31a56598f29 100644
> >> --- a/mm/memcontrol.c
> >> +++ b/mm/memcontrol.c
> >> @@ -2780,6 +2780,10 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> >>  	do {
> >>  		bool mem_high, swap_high;
> >>  
> >> +		/* There is no need for root memcg to check high limit */
> >> +		if (mem_cgroup_is_root(memcg))
> >> +			break;
> >> +
> >>  		mem_high = page_counter_read(&memcg->memory) >
> >>  			READ_ONCE(memcg->memory.high);
> >>  		swap_high = page_counter_read(&memcg->swap) >
> >> -- 
> >> 2.25.1
> > 
> 
> test steps:
> 1. mkdir -p /sys/fs/cgroup/memory/test
> 2. echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs
> 3. ./mmap_test
> 
> The test result show that with or without the patch, the time taken is almost the same.

This is in line with my expectation. So the question is whether the
additional check is really worth it. 
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2023-02-21 12:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  9:45 Haifeng Xu
2023-02-14 15:56 ` Michal Hocko
2023-02-21 10:29   ` Haifeng Xu
2023-02-21 12:20     ` Michal Hocko [this message]
2023-02-21 14:21       ` Haifeng Xu
2023-02-21 15:21         ` Michal Hocko

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=Y/S3GHT1P6awZaPb@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=haifeng.xu@shopee.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=shakeelb@google.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