All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Wei Xu <weixugc@google.com>, Yosry Ahmed <yosryahmed@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Shakeel Butt <shakeelb@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
	Zefan Li <lizefan.x@bytedance.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Cgroups <cgroups@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>, Jonathan Corbet <corbet@lwn.net>,
	Yu Zhao <yuzhao@google.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Greg Thelen <gthelen@google.com>,
	Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface
Date: Thu, 7 Apr 2022 09:35:30 +0200	[thread overview]
Message-ID: <Yk6UQrjqSQnePdxe@dhcp22.suse.cz> (raw)
In-Reply-To: <877d82vi13.fsf@yhuang6-desk2.ccr.corp.intel.com>

On Wed 06-04-22 14:32:24, Huang, Ying wrote:
[...]
> I think we should define the interface not from the current
> implementation point of view, but from the requirement point of view.

Agreed!

> For proactive reclaim, per my understanding, the requirement is,
> 
>   we found that there's some cold pages in some workloads, so we can
>   take advantage of the proactive reclaim to reclaim some pages so that
>   other workload can use the freed memory.

We are talking about memcg here so this is not as much a matter of free
memory as it is to decrease the amount of charged memory. Demotion
cannot achieve that.

> For proactive demotion, per my understanding, the requirement could be,
> 
>   We found that there's some cold pages in fast memory (e.g. DRAM) in
>   some workloads, so we can take advantage of the proactive demotion to
>   demote some pages so that other workload can use the freed fast
>   memory.  Given the DRAM partition support Tim (Cced) is working on.

Yes, this is essentially a kernel assisted memory migration. Userspace
can migrate memory but the issue is that it doesn't have any information
on the aging so the migration has hard time to find suitable memory to
migrate. If we really need this functionality then it would deserve a
separate interface IMHO.

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2022-04-07  7:36 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  8:41 [PATCH resend] memcg: introduce per-memcg reclaim interface Yosry Ahmed
2022-03-31 17:25 ` Roman Gushchin
2022-04-01  6:01   ` Wei Xu
2022-04-01  6:01     ` Wei Xu
2022-04-01  9:11   ` Yosry Ahmed
2022-04-01  9:11     ` Yosry Ahmed
2022-04-01 18:39     ` Roman Gushchin
2022-04-01 21:13       ` Johannes Weiner
2022-04-01 21:13         ` Johannes Weiner
2022-04-01 21:21         ` Roman Gushchin
2022-04-01 21:38           ` Wei Xu
2022-04-01 21:51           ` Johannes Weiner
2022-04-04 17:14             ` Shakeel Butt
2022-04-04 17:13       ` Yosry Ahmed
2022-04-04 17:55         ` Roman Gushchin
2022-04-01  9:15   ` Yosry Ahmed
2022-04-01  9:15     ` Yosry Ahmed
2022-04-01 15:41     ` Shakeel Butt
2022-04-01 13:49   ` Michal Hocko
2022-04-01 16:58     ` Roman Gushchin
2022-04-04  8:44       ` Michal Hocko
2022-04-04 18:25         ` Roman Gushchin
2022-03-31 19:25 ` Johannes Weiner
2022-04-01  0:33 ` Andrew Morton
2022-04-01  0:33   ` Andrew Morton
2022-04-01  3:38   ` Wei Xu
2022-04-01  9:17     ` Yosry Ahmed
2022-04-01  9:17       ` Yosry Ahmed
2022-04-01 13:03       ` Michal Hocko
2022-04-01 13:03         ` Michal Hocko
2022-04-01  3:05 ` Chen Wandun
2022-04-01  3:05   ` Chen Wandun
2022-04-01  9:20   ` Yosry Ahmed
2022-04-01  9:48     ` Chen Wandun
2022-04-01  9:48       ` Chen Wandun
2022-04-01 10:02       ` Yosry Ahmed
2022-04-01  4:05 ` Wei Xu
2022-04-01  4:05   ` Wei Xu
2022-04-01  9:22   ` Yosry Ahmed
2022-04-01  9:22     ` Yosry Ahmed
2022-04-01 15:22   ` Johannes Weiner
2022-04-01 20:14     ` Wei Xu
2022-04-01 21:07       ` Johannes Weiner
2022-04-01 21:07         ` Johannes Weiner
2022-04-04 17:08       ` Shakeel Butt
2022-04-05  2:30         ` Wei Xu
2022-04-05 10:09         ` Michal Koutný
2022-04-01  8:39 ` Vaibhav Jain
2022-04-01  9:23   ` Yosry Ahmed
2022-04-04  3:50     ` Vaibhav Jain
2022-04-04 17:18       ` Yosry Ahmed
2022-04-01 13:54 ` Michal Hocko
2022-04-01 16:56   ` Wei Xu
2022-04-01 16:56     ` Wei Xu
2022-04-02  8:13     ` Huang, Ying
2022-04-03  6:46       ` Wei Xu
2022-04-03  6:56       ` Wei Xu
2022-04-06  0:48         ` Huang, Ying
2022-04-06  1:07           ` Wei Xu
2022-04-06  1:07             ` Wei Xu
2022-04-06  2:49             ` Huang, Ying
2022-04-06  2:49               ` Huang, Ying
2022-04-06  5:02               ` Wei Xu
2022-04-06  6:32                 ` Huang, Ying
2022-04-06  7:05                   ` Wei Xu
2022-04-06  8:49                     ` Huang, Ying
2022-04-06  8:49                       ` Huang, Ying
2022-04-06 20:16                       ` Wei Xu
2022-04-06 20:16                         ` Wei Xu
2022-04-07  7:35                   ` Michal Hocko [this message]
2022-04-07 21:26               ` Tim Chen
2022-04-07 22:07                 ` Wei Xu
2022-04-07 22:12                 ` Wei Xu
2022-04-07 22:12                   ` Wei Xu
2022-04-07 23:11                   ` Tim Chen
2022-04-08  2:10                     ` Wei Xu
2022-04-08  2:10                       ` Wei Xu
2022-04-08  3:08                       ` Huang, Ying
2022-04-08  4:10                         ` Wei Xu
2022-04-08  4:10                           ` Wei Xu
2022-04-04 17:09   ` Yosry Ahmed

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=Yk6UQrjqSQnePdxe@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizefan.x@bytedance.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tj@kernel.org \
    --cc=weixugc@google.com \
    --cc=ying.huang@intel.com \
    --cc=yosryahmed@google.com \
    --cc=yuzhao@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.