From: Waiman Long <longman@redhat.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeelb@google.com>,
Muchun Song <songmuchun@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, Tejun Heo <tj@kernel.org>,
Chris Down <chris@chrisdown.name>
Subject: Re: [PATCH] mm/memcontrol: Don't increase effective low/min if no protection needed
Date: Tue, 11 Oct 2022 13:00:22 -0400 [thread overview]
Message-ID: <defdb421-342e-ebcb-d7f0-005559dd1e0d@redhat.com> (raw)
In-Reply-To: <Y0WOPZxWSnUjzZ8e@dhcp22.suse.cz>
On 10/11/22 11:39, Michal Hocko wrote:
> On Tue 11-10-22 10:30:15, Waiman Long wrote:
>> Since commit bc50bcc6e00b ("mm: memcontrol: clean up and document
>> effective low/min calculations"), the effective low/min protections can
>> be non-zero even if the corresponding memory.low/min values are 0. That
>> can surprise users to see MEMCG_LOW events even when the memory.low
>> value is not set. One example is the LTP's memcontrol04 test which fails
>> because it detects some MEMCG_LOW events for a cgroup with a memory.min
>> value of 0.
> Is this with memory_recursiveprot mount option?
Yes, the memory_recursiveprot mount option is indeed turned on.
>
>> Fix this by updating effective_protection() to not returning a non-zero
>> low/min protection values if the corresponding memory.low/min values
>> or those of its parent are 0.
>>
>> Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/min calculations")
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> mm/memcontrol.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index b69979c9ced5..893d4d5e518a 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -6660,6 +6660,9 @@ static unsigned long effective_protection(unsigned long usage,
>> unsigned long protected;
>> unsigned long ep;
>>
>> + if (!setting || !parent_effective)
>> + return 0UL; /* No protection is needed */
>> +
> This will break the above memory_recursiveprot AFAICS.
You are right about that. An alternative way to address this issue is to
disable memory low event when memory.low isn't set. An user who want to
track memory.low event has to set it to a non-zero value. Would that be
acceptable?
Cheers,
Longman
next prev parent reply other threads:[~2022-10-11 17:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 14:30 Waiman Long
2022-10-11 15:39 ` Michal Hocko
2022-10-11 17:00 ` Waiman Long [this message]
2022-10-11 17:04 ` Tejun Heo
2022-10-11 17:14 ` Waiman Long
2022-10-11 19:01 ` Michal Hocko
2022-10-17 22:46 ` Michal Koutný
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=defdb421-342e-ebcb-d7f0-005559dd1e0d@redhat.com \
--to=longman@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
--cc=tj@kernel.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