linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 2/3] mm: Force update of mem cgroup soft limit tree on usage excess
Date: Sat, 20 Feb 2021 08:23:15 -0800	[thread overview]
Message-ID: <0f8117ef-c461-e2be-ea7a-6cbf727c9bb5@linux.intel.com> (raw)
In-Reply-To: <884d7559-e118-3773-351d-84c02642ca96@linux.intel.com>



On 2/19/21 10:59 AM, Tim Chen wrote:
> 
> 
> On 2/19/21 1:11 AM, Michal Hocko wrote:

>>
>> Soft limit is evaluated every THRESHOLDS_EVENTS_TARGET * SOFTLIMIT_EVENTS_TARGET.
>> If all events correspond with a newly charged memory and the last event
>> was just about the soft limit boundary then we should be bound by 128k
>> pages (512M and much more if this were huge pages) which is a lot!
>> I haven't realized this was that much. Now I see the problem. This would
>> be a useful information for the changelog.
>>
>> Your fix is focusing on the over-the-limit boundary which will solve the
>> problem but wouldn't that lead to to updates happening too often in
>> pathological situation when a memcg would get reclaimed immediatelly?
> 
> Not really immediately.  The memcg that has the most soft limit excess will
> be chosen for page reclaim, which is the way it should be.  
> It is less likely that a memcg that just exceeded
> the soft limit becomes the worst offender immediately.  With the fix, we make
> sure that it is on the bad guys list and will not be ignored and be chosen
> eventually for reclaim.  It will not sneakily increase its memory usage
> slowly.   
> 

I should also mention that the forced update is only performed once when
the memcg first exceeded the soft limit as we check whether the memcg
is already in the soft limit tree due to the !mz->on_tree check.
+	if (mz && !mz->on_tree && soft_limit_excess(mz->memcg) > 0)
+		force_update = true;

So the update overhead is very low. 

Tim


  reply	other threads:[~2021-02-20 16:23 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
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 [this message]
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=0f8117ef-c461-e2be-ea7a-6cbf727c9bb5@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).