From: Michal Hocko <mhocko@suse.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Hugh Dickins <hughd@google.com>,
Yosry Ahmed <yosryahmed@google.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org,
Meta kernel team <kernel-team@meta.com>
Subject: Re: [PATCH v1 1/6] memcg-v1: fully deprecate move_charge_at_immigrate
Date: Fri, 25 Oct 2024 08:54:26 +0200 [thread overview]
Message-ID: <ZxtAoo49HRces0fN@tiehlicka> (raw)
In-Reply-To: <20241025012304.2473312-2-shakeel.butt@linux.dev>
On Thu 24-10-24 18:22:58, Shakeel Butt wrote:
> Proceed with the complete deprecation of memcg v1's charge moving
> feature. The deprecation warning has been in the kernel for almost two
> years and has been ported to all stable kernel since. Now is the time to
> fully deprecate this feature.
>
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
>
> Changes since RFC:
> - Writing 0 to memory.move_charge_at_immigrate is allowed.
>
> .../admin-guide/cgroup-v1/memory.rst | 82 +------------------
> mm/memcontrol-v1.c | 14 +---
> 2 files changed, 5 insertions(+), 91 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
> index 270501db9f4e..286d16fc22eb 100644
> --- a/Documentation/admin-guide/cgroup-v1/memory.rst
> +++ b/Documentation/admin-guide/cgroup-v1/memory.rst
> @@ -90,9 +90,7 @@ Brief summary of control files.
> used.
> memory.swappiness set/show swappiness parameter of vmscan
> (See sysctl's vm.swappiness)
> - memory.move_charge_at_immigrate set/show controls of moving charges
> - This knob is deprecated and shouldn't be
> - used.
> + memory.move_charge_at_immigrate This knob is deprecated.
> memory.oom_control set/show oom controls.
> This knob is deprecated and shouldn't be
> used.
> @@ -243,10 +241,6 @@ behind this approach is that a cgroup that aggressively uses a shared
> page will eventually get charged for it (once it is uncharged from
> the cgroup that brought it in -- this will happen on memory pressure).
>
> -But see :ref:`section 8.2 <cgroup-v1-memory-movable-charges>` when moving a
> -task to another cgroup, its pages may be recharged to the new cgroup, if
> -move_charge_at_immigrate has been chosen.
> -
> 2.4 Swap Extension
> --------------------------------------
>
> @@ -756,78 +750,8 @@ If we want to change this to 1G, we can at any time use::
>
> THIS IS DEPRECATED!
>
> -It's expensive and unreliable! It's better practice to launch workload
> -tasks directly from inside their target cgroup. Use dedicated workload
> -cgroups to allow fine-grained policy adjustments without having to
> -move physical pages between control domains.
> -
> -Users can move charges associated with a task along with task migration, that
> -is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
> -This feature is not supported in !CONFIG_MMU environments because of lack of
> -page tables.
> -
> -8.1 Interface
> --------------
> -
> -This feature is disabled by default. It can be enabled (and disabled again) by
> -writing to memory.move_charge_at_immigrate of the destination cgroup.
> -
> -If you want to enable it::
> -
> - # echo (some positive value) > memory.move_charge_at_immigrate
> -
> -.. note::
> - Each bits of move_charge_at_immigrate has its own meaning about what type
> - of charges should be moved. See :ref:`section 8.2
> - <cgroup-v1-memory-movable-charges>` for details.
> -
> -.. note::
> - Charges are moved only when you move mm->owner, in other words,
> - a leader of a thread group.
> -
> -.. note::
> - If we cannot find enough space for the task in the destination cgroup, we
> - try to make space by reclaiming memory. Task migration may fail if we
> - cannot make enough space.
> -
> -.. note::
> - It can take several seconds if you move charges much.
> -
> -And if you want disable it again::
> -
> - # echo 0 > memory.move_charge_at_immigrate
> -
> -.. _cgroup-v1-memory-movable-charges:
> -
> -8.2 Type of charges which can be moved
> ---------------------------------------
> -
> -Each bit in move_charge_at_immigrate has its own meaning about what type of
> -charges should be moved. But in any case, it must be noted that an account of
> -a page or a swap can be moved only when it is charged to the task's current
> -(old) memory cgroup.
> -
> -+---+--------------------------------------------------------------------------+
> -|bit| what type of charges would be moved ? |
> -+===+==========================================================================+
> -| 0 | A charge of an anonymous page (or swap of it) used by the target task. |
> -| | You must enable Swap Extension (see 2.4) to enable move of swap charges. |
> -+---+--------------------------------------------------------------------------+
> -| 1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory) |
> -| | and swaps of tmpfs file) mmapped by the target task. Unlike the case of |
> -| | anonymous pages, file pages (and swaps) in the range mmapped by the task |
> -| | will be moved even if the task hasn't done page fault, i.e. they might |
> -| | not be the task's "RSS", but other task's "RSS" that maps the same file. |
> -| | The mapcount of the page is ignored (the page can be moved independent |
> -| | of the mapcount). You must enable Swap Extension (see 2.4) to |
> -| | enable move of swap charges. |
> -+---+--------------------------------------------------------------------------+
> -
> -8.3 TODO
> ---------
> -
> -- All of moving charge operations are done under cgroup_mutex. It's not good
> - behavior to hold the mutex too long, so we may need some trick.
> +Reading memory.move_charge_at_immigrate will always return 0 and writing
> +to it will always return -EINVAL.
>
> 9. Memory thresholds
> ====================
> diff --git a/mm/memcontrol-v1.c b/mm/memcontrol-v1.c
> index 81d8819f13cd..9b3b1a446c65 100644
> --- a/mm/memcontrol-v1.c
> +++ b/mm/memcontrol-v1.c
> @@ -593,29 +593,19 @@ static inline int mem_cgroup_move_swap_account(swp_entry_t entry,
> static u64 mem_cgroup_move_charge_read(struct cgroup_subsys_state *css,
> struct cftype *cft)
> {
> - return mem_cgroup_from_css(css)->move_charge_at_immigrate;
> + return 0;
> }
>
> #ifdef CONFIG_MMU
> static int mem_cgroup_move_charge_write(struct cgroup_subsys_state *css,
> struct cftype *cft, u64 val)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(css);
> -
> pr_warn_once("Cgroup memory moving (move_charge_at_immigrate) is deprecated. "
> "Please report your usecase to linux-mm@kvack.org if you "
> "depend on this functionality.\n");
>
> - if (val & ~MOVE_MASK)
> + if (val != 0)
> return -EINVAL;
> -
> - /*
> - * No kind of locking is needed in here, because ->can_attach() will
> - * check this value once in the beginning of the process, and then carry
> - * on with stale data. This means that changes to this value will only
> - * affect task migrations starting after the change.
> - */
> - memcg->move_charge_at_immigrate = val;
> return 0;
> }
> #else
> --
> 2.43.5
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-10-25 6:54 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 1:22 [PATCH v1 0/6] memcg-v1: fully deprecate charge moving Shakeel Butt
2024-10-24 6:57 ` [RFC PATCH 0/3] " Shakeel Butt
2024-10-24 6:57 ` [RFC PATCH 1/3] memcg-v1: fully deprecate move_charge_at_immigrate Shakeel Butt
2024-10-24 9:14 ` Michal Hocko
2024-10-24 16:51 ` Roman Gushchin
2024-10-24 17:16 ` Shakeel Butt
2024-10-24 16:49 ` Roman Gushchin
2024-10-24 6:57 ` [RFC PATCH 2/3] memcg-v1: remove charge move code Shakeel Butt
2024-10-24 9:14 ` Michal Hocko
2024-10-24 16:50 ` Roman Gushchin
2024-10-24 6:57 ` [RFC PATCH 3/3] memcg-v1: remove memcg move locking code Shakeel Butt
2024-10-24 9:16 ` Michal Hocko
2024-10-24 17:23 ` Shakeel Butt
2024-10-24 18:54 ` Roman Gushchin
2024-10-24 19:38 ` Shakeel Butt
2024-10-24 16:50 ` Roman Gushchin
2024-10-24 17:26 ` Shakeel Butt
2024-10-24 19:45 ` Michal Hocko
2024-10-24 20:32 ` Yosry Ahmed
2024-10-24 21:08 ` Michal Hocko
2024-10-25 1:23 ` Shakeel Butt
2024-10-25 1:22 ` [PATCH v1 1/6] memcg-v1: fully deprecate move_charge_at_immigrate Shakeel Butt
2024-10-25 6:54 ` Michal Hocko [this message]
2024-10-28 13:53 ` Johannes Weiner
2024-10-25 1:22 ` [PATCH v1 2/6] memcg-v1: remove charge move code Shakeel Butt
2024-10-28 10:22 ` David Hildenbrand
2024-10-28 10:40 ` David Hildenbrand
2024-10-28 13:54 ` Johannes Weiner
2024-10-25 1:23 ` [PATCH v1 3/6] memcg-v1: no need for memcg locking for dirty tracking Shakeel Butt
2024-10-25 6:56 ` Michal Hocko
2024-10-25 16:22 ` Shakeel Butt
2024-10-25 17:40 ` Roman Gushchin
2024-10-28 14:00 ` Johannes Weiner
2024-10-25 1:23 ` [PATCH v1 4/6] memcg-v1: no need for memcg locking for writeback tracking Shakeel Butt
2024-10-25 6:57 ` Michal Hocko
2024-10-25 17:40 ` Roman Gushchin
2024-10-28 14:00 ` Johannes Weiner
2024-10-25 1:23 ` [PATCH v1 5/6] memcg-v1: no need for memcg locking for MGLRU Shakeel Butt
2024-10-25 17:41 ` Roman Gushchin
2024-10-26 3:55 ` Yu Zhao
2024-10-26 6:20 ` Shakeel Butt
2024-10-26 6:34 ` Shakeel Butt
2024-10-26 15:26 ` Yu Zhao
2024-11-04 17:30 ` Yu Zhao
2024-11-04 21:38 ` Andrew Morton
2024-11-04 22:04 ` Shakeel Butt
2024-11-04 22:04 ` Yu Zhao
2024-11-04 22:08 ` Yu Zhao
2024-11-04 22:18 ` Andrew Morton
2024-10-25 1:23 ` [PATCH v1 6/6] memcg-v1: remove memcg move locking code Shakeel Butt
2024-10-25 6:59 ` Michal Hocko
2024-10-25 17:42 ` Roman Gushchin
2024-10-26 3:58 ` Yu Zhao
2024-10-26 6:26 ` Shakeel Butt
2024-10-28 14:02 ` Johannes Weiner
2024-10-25 1:33 ` [PATCH v1 0/6] memcg-v1: fully deprecate charge moving Shakeel Butt
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=ZxtAoo49HRces0fN@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kernel-team@meta.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=yosryahmed@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;
as well as URLs for NNTP newsgroup(s).