From: Tim Chen <tim.c.chen@linux.intel.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Dave Hansen <dave.hansen@intel.com>,
Ying Huang <ying.huang@intel.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] mm: Fix dropped memcg from mem cgroup soft limit tree
Date: Thu, 18 Feb 2021 10:30:20 -0800 [thread overview]
Message-ID: <c3ffa2cb-cb2c-20b7-d722-c875934992e9@linux.intel.com> (raw)
In-Reply-To: <YC4kV7dkJpxjW+df@dhcp22.suse.cz>
On 2/18/21 12:24 AM, Michal Hocko wrote:
>
> I have already acked this patch in the previous version along with Fixes
> tag. It seems that my review feedback has been completely ignored also
> for other patches in this series.
Michal,
My apology. Our mail system screwed up and there are some mail missing
from our mail system that I completely missed your mail.
Only saw them now after I looked into the lore.kernel.org.
Responding to your comment:
>Have you observed this happening in the real life? I do agree that the
>threshold based updates of the tree is not ideal but the whole soft
>reclaim code is far from optimal. So why do we care only now? The
>feature is essentially dead and fine tuning it sounds like a step back
>to me.
Yes, I did see the issue mentioned in patch 2 breaking soft limit
reclaim for cgroup v1. There are still some of our customers using
cgroup v1 so we will like to fix this if possible.
For patch 3 regarding the uncharge_batch, it
is more of an observation that we should uncharge in batch of same node
and not prompted by actual workload.
Thinking more about this, the worst that could happen
is we could have some entries in the soft limit tree that overestimate
the memory used. The worst that could happen is a soft page reclaim
on that cgroup. The overhead from extra memcg event update could
be more than a soft page reclaim pass. So let's drop patch 3
for now.
Let me know if you will like me to resend patch 1 with the fixes tag
for commit 4e41695356fb ("memory controller: soft limit reclaim on contention")
and if there are any changes I should make for patch 2.
Thanks.
Tim
next prev parent reply other threads:[~2021-02-18 18:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 20:41 [PATCH v2 0/3] Soft limit memory management bug fixes Tim Chen
2021-02-17 20:41 ` [PATCH v2 1/3] mm: Fix dropped memcg from mem cgroup soft limit tree Tim Chen
2021-02-18 8:24 ` Michal Hocko
2021-02-18 18:30 ` Tim Chen [this message]
2021-02-18 19:13 ` Michal Hocko
2021-02-18 19:51 ` Tim Chen
2021-02-18 19:13 ` Michal Hocko
2021-03-04 17:35 ` Tim Chen
2021-03-05 9:11 ` Michal Hocko
2021-03-05 19:07 ` Tim Chen
2021-03-08 8:34 ` Michal Hocko
2021-02-17 20:41 ` [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess Tim Chen
2021-02-19 9:11 ` Michal Hocko
2021-02-19 18:59 ` Tim Chen
2021-02-20 16:23 ` Tim Chen
2021-02-22 8:40 ` Michal Hocko
2021-02-22 17:41 ` Tim Chen
2021-02-22 19:09 ` Michal Hocko
2021-02-22 19:23 ` Tim Chen
2021-02-22 19:48 ` Tim Chen
2021-02-24 11:53 ` Michal Hocko
2021-02-25 22:48 ` Tim Chen
2021-02-26 8:52 ` Michal Hocko
2021-02-27 0:56 ` Tim Chen
2021-03-01 7:39 ` Michal Hocko
2021-02-25 22:25 ` Tim Chen
2021-03-02 6:25 ` [mm] 4f09feb8bf: vm-scalability.throughput -4.3% regression kernel test robot
2021-02-17 20:41 ` [PATCH v2 3/3] mm: Fix missing mem cgroup soft limit tree updates Tim Chen
2021-02-18 5:56 ` Johannes Weiner
2021-02-22 18:38 ` Tim Chen
2021-02-23 15:18 ` Johannes Weiner
2021-02-19 9:16 ` Michal Hocko
2021-02-19 19:28 ` Tim Chen
2021-02-22 8:41 ` Michal Hocko
2021-02-22 17:45 ` Tim Chen
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=c3ffa2cb-cb2c-20b7-d722-c875934992e9@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=vdavydov.dev@gmail.com \
--cc=ying.huang@intel.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).