All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ridong Chen <ridong.chen@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>, Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	David Hildenbrand <david@kernel.org>,
	Yuanchu Xie <yuanchu@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH 1/2] memcg: move mem_cgroup_swappiness to memcontrol.h
Date: Tue, 14 Jul 2026 19:31:05 +0800	[thread overview]
Message-ID: <bfb1cfa1-691a-4bac-beb6-caef9b3ac4e8@linux.dev> (raw)
In-Reply-To: <CAGsJ_4x7cg-L_OzCdyZy+8zoKptVi-Jh18k1HRkvTBTbn-EQRA@mail.gmail.com>



On 7/14/2026 6:21 PM, Barry Song wrote:
> On Tue, Jul 14, 2026 at 3:43 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>>
>>
>> On 7/14/2026 9:48 AM, Barry Song wrote:
>>> On Tue, Jul 14, 2026 at 9:43 AM Barry Song <baohua@kernel.org> wrote:
>>>>
>>>> On Tue, Jul 14, 2026 at 9:20 AM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 7/13/2026 11:08 PM, Barry Song wrote:
>>>>>> On Sat, Jul 11, 2026 at 5:12 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>>>>
>>>>>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>>>>>
>>>>>>> The per-memcg swappiness knob is v1-only; v2 always uses global
>>>>>>> vm_swappiness and ignores the per-cgroup field.
>>>>>>>
>>>>>>> Guard memcg->swappiness with CONFIG_MEMCG_V1, and move the helper
>>>>>>> to memcontrol.h where it belongs.
>>>>>>>
>>>>>>> No functional change for v1; v2-only kernels drop the unused field.
>>>>>>>
>>>>>>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>>>>>>> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
>>>>>>
>>>>>> Reviewed-by: Barry Song <baohua@kernel.org>
>>>>>>
>>>>>> With some nits.
>>>>>>
>>>>>>> ---
>>>>>> [...]
>>>>>>>            struct mem_cgroup_per_node *nodeinfo[];
>>>>>>> @@ -365,6 +366,9 @@ enum objext_flags {
>>>>>>>
>>>>>>>     #define OBJEXTS_FLAGS_MASK (__NR_OBJEXTS_FLAGS - 1)
>>>>>>>
>>>>>>> +/* Defined in mm/vmscan.c; used by mem_cgroup_swappiness(). */
>>>>>>> +extern int vm_swappiness;
>>>>>>
>>>>>> This is a bit unusual. I'm not sure whether mm/swap.h would be
>>>>>> a more appropriate place for this.
>>>>>>
>>>>> Thank you for your reply.
>>>>>
>>>>> The vm_swappiness variable is not utilized within mm/swap.c.
>>>>> Furthermore, since memcontrol.h does not include swap.h, retaining the
>>>>> extern int vm_swappiness declaration in mm/swap.h will result in a
>>>>> compilation failure.
>>>>
>>>> If this is the case, it still seems better to keep
>>>> extern int vm_swappiness in include/linux/swap.h.
>>>>
>>>> Then we don't need the comment:
>>>> /* Defined in mm/vmscan.c; used by mem_cgroup_swappiness(). */
>>>>
>>>> It also makes it clearer that vm_swappiness is an extern variable
>>>> belonging to the swap module, rather than the memcontrol module.
>>>
>>> BTW, if mem_c_group_swappiness() and vm_swappiness are only used
>>> within mm/, could all of these be moved to mm/swap.h and
>>> mm/internal.h instead?
>>>
>>> We are making a big effort to move many unrelated things out of
>>> include/linux/swap.h recently. Could you check?
>>>
>>> https://lore.kernel.org/linux-mm/20260708-ch-swap-series-plus-folio-lru-cleanup-v9-0-2bc72b4f8730@gmail.com/
>>
>> Good suggestion. Moving them to mm/internal.h makes sense. Will update
>> in the next version.
> 
> Either mm/swap.h or mm/internal.h.
> vm_swappiness probably belongs in mm/swap.h rather than
> mm/internal.h, right?
> 
> BTW, I am not particularly eager about this cleanup;
> it could be done later as a separate patch.
> 
> If you decide not to do the cleanup, I think it would be better to
> leave "extern int vm_swappiness" in include/linux/swap.h rather than
> declaring it in include/linux/memcontrol.h?
I noticed that some swap-related macros are already defined in 
mm/internal.h, so I'm planning to place the code right after them for 
better grouping. Does that work for you?

```
...
#define MEMCG_RECLAIM_MAY_SWAP (1 << 1)
#define MEMCG_RECLAIM_PROACTIVE (1 << 2)
#define MIN_SWAPPINESS 0
#define MAX_SWAPPINESS 200

/* Just reclaim from anon folios in proactive memory reclaim */
#define SWAPPINESS_ANON_ONLY (MAX_SWAPPINESS + 1)

extern int vm_swappiness;

static inline int mem_cgroup_swappiness(struct mem_cgroup *memcg)
{
#ifdef CONFIG_MEMCG_V1
	/* Cgroup2 doesn't have per-cgroup swappiness */
	if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
		return READ_ONCE(vm_swappiness);

	/* root ? */
	if (mem_cgroup_disabled() || mem_cgroup_is_root(memcg))
		return READ_ONCE(vm_swappiness);

	return READ_ONCE(memcg->swappiness);
#else
	return READ_ONCE(vm_swappiness);
#endif
}
...
```


-- 
Best regards
Ridong



  reply	other threads:[~2026-07-14 11:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11  9:11 [PATCH 0/2] mm: fix node reclaim swappiness handling Ridong Chen
2026-07-11  9:11 ` [PATCH 1/2] memcg: move mem_cgroup_swappiness to memcontrol.h Ridong Chen
2026-07-13 15:08   ` Barry Song
2026-07-14  1:19     ` Ridong Chen
2026-07-14  1:43       ` Barry Song
2026-07-14  1:48         ` Barry Song
2026-07-14  7:42           ` Ridong Chen
2026-07-14 10:21             ` Barry Song
2026-07-14 11:31               ` Ridong Chen [this message]
2026-07-14 13:46                 ` Barry Song
2026-07-11  9:11 ` [PATCH 2/2] mm: vmscan: fix node reclaim ignoring swappiness parameter Ridong Chen
2026-07-13 11:28   ` Johannes Weiner
2026-07-14  7:58     ` Ridong Chen
2026-07-13 15:16   ` Barry Song
2026-07-14  1:10     ` Ridong 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=bfb1cfa1-691a-4bac-beb6-caef9b3ac4e8@linux.dev \
    --to=ridong.chen@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chenridong@xiaomi.com \
    --cc=chrisl@kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=yuanchu@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.