[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e40aa928-4bcd-4acd-924a-d2f154845908@vivo.com>
Date: Thu, 14 Dec 2023 10:00:02 +0800
From: Huan Yang <11133793@...o.com>
To: Dan Schatzberg <schatzberg.dan@...il.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Yosry Ahmed <yosryahmed@...gle.com>, Huan Yang <link@...o.com>,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
linux-mm@...ck.org, Tejun Heo <tj@...nel.org>,
Zefan Li <lizefan.x@...edance.com>,
Jonathan Corbet <corbet@....net>,
Michal Hocko <mhocko@...nel.org>,
Shakeel Butt <shakeelb@...gle.com>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Chris Li <chrisl@...nel.org>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Yue Zhao <findns94@...il.com>, Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH V4 1/2] mm: add defines for min/max swappiness
在 2023/12/14 0:41, Dan Schatzberg 写道:
> [Some people who received this message don't often get email from schatzberg.dan@...il.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Wed, Dec 13, 2023 at 09:58:26AM +0800, Huan Yang wrote:
>> 在 2023/12/13 9:38, Dan Schatzberg 写道:
>>> [????????? schatzberg.dan@...il.com ????????? https://aka.ms/LearnAboutSenderIdentification,????????????]
>>>
>>> We use the constants 0 and 200 in a few places in the mm code when
>>> referring to the min and max swappiness. This patch adds MIN_SWAPPINESS
>>> and MAX_SWAPPINESS #defines to improve clarity. There are no functional
>>> changes.
>>>
>>> Signed-off-by: Dan Schatzberg <schatzberg.dan@...il.com>
>>> ---
>>> include/linux/swap.h | 2 ++
>>> mm/memcontrol.c | 2 +-
>>> mm/vmscan.c | 10 +++++-----
>>> 3 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/linux/swap.h b/include/linux/swap.h
>>> index f6dd6575b905..e2ab76c25b4a 100644
>>> --- a/include/linux/swap.h
>>> +++ b/include/linux/swap.h
>>> @@ -407,6 +407,8 @@ extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
>>>
>>> #define MEMCG_RECLAIM_MAY_SWAP (1 << 1)
>>> #define MEMCG_RECLAIM_PROACTIVE (1 << 2)
>>> +#define MIN_SWAPPINESS 0
>>> +#define MAX_SWAPPINESS 200
>> Do MAX_SWAPPINESS apply for all swapppiness? If so, maybe better change
>> swappiness sysctl define:
>> ```
>> sysctl.c:
>>
>> {
>> .procname = "swappiness",
>> .data = &vm_swappiness,
>> .maxlen = sizeof(vm_swappiness),
>> .mode = 0644,
>> .proc_handler = proc_dointvec_minmax,
>> .extra1 = SYSCTL_ZERO,
>> .extra2 = SYSCTL_TWO_HUNDRED,
>> },
>>
>> ```
>>
>> Here hard code swappiness in [0, 200], and now add a new define.
> Yes, MAX_SWAPPINESS is a hard limit. I'm not sure what you're
> proposing here - the SYSCTL_ZERO and SYSCTL_TWO_HUNDRED values are a
I mean, MAX_SWAPPINESS and SYSCTL_TWO_HUNDRED all limit swappiness,
but are different definitions.
If swappiness change 200 into 400, you need to change here extra2 and your
MAX_SWAPPINESS. It's wierd.
> little different than the defines I added. I think most of the value
> is just consistently using the defines in the core mm code.
>
>> And many other code hard reference 200 into max value of swappiness, like:
>>
>> ```
>> memcontrol.c:
>> static int mem_cgroup_swappiness_write(struct cgroup_subsys_state *css,
>> struct cftype *cft, u64 val)
>> {
>> struct mem_cgroup *memcg = mem_cgroup_from_css(css);
>>
>> if (val > 200)
>> return -EINVAL;
>>
>> if (!mem_cgroup_is_root(memcg))
>> memcg->swappiness = val;
>> else
>> vm_swappiness = val;
>>
>> return 0;
>> }
> This one is already fixed in my patch.
Powered by blists - more mailing lists