* [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG @ 2023-07-06 11:28 Miaohe Lin 2023-07-07 1:47 ` Muchun Song 0 siblings, 1 reply; 5+ messages in thread From: Miaohe Lin @ 2023-07-06 11:28 UTC (permalink / raw) To: akpm, hannes, mhocko, roman.gushchin, shakeelb Cc: muchun.song, cgroups, linux-kernel, linux-mm, linmiaohe MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove unneeded !CONFIG_MEMCG variant. Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> --- include/linux/memcontrol.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 5818af8eca5a..634a282099bf 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1158,7 +1158,6 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, #else /* CONFIG_MEMCG */ #define MEM_CGROUP_ID_SHIFT 0 -#define MEM_CGROUP_ID_MAX 0 static inline struct mem_cgroup *folio_memcg(struct folio *folio) { -- 2.33.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG 2023-07-06 11:28 [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG Miaohe Lin @ 2023-07-07 1:47 ` Muchun Song [not found] ` <892B507C-CFE8-4792-BA5F-3C698290A8EE-fxUVXftIFDnyG1zEObXtfA@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Muchun Song @ 2023-07-07 1:47 UTC (permalink / raw) To: Miaohe Lin Cc: Andrew Morton, Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt, cgroups, LKML, Linux Memory Management List > On Jul 6, 2023, at 19:28, Miaohe Lin <linmiaohe@huawei.com> wrote: > > MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove > unneeded !CONFIG_MEMCG variant. > > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> MEM_CGROUP_ID_MAX is also only used in mem_cgroup_alloc(), maybe you also could move it from memcontrol.h to memcontrol.c. And define it as: #define MEM_CGROUP_ID_MAX ((1U << MEM_CGROUP_ID_SHIFT) - 1) I am not suggesting defining it as USHRT_MAX, because if someone changes MEM_CGROUP_ID_SHIFT in the future, then MEM_CGROUP_ID_MAX will not updated accordingly. For this patch, LGTM. Reviewed-by: Muchun Song <songmuchun@bytedance.com> Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <892B507C-CFE8-4792-BA5F-3C698290A8EE-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>]
* Re: [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG [not found] ` <892B507C-CFE8-4792-BA5F-3C698290A8EE-fxUVXftIFDnyG1zEObXtfA@public.gmane.org> @ 2023-07-07 2:06 ` Miaohe Lin [not found] ` <61ce2910-f3de-cfb7-bdd3-546ade0cb6f3-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Miaohe Lin @ 2023-07-07 2:06 UTC (permalink / raw) To: Muchun Song Cc: Andrew Morton, Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt, cgroups-u79uwXL29TY76Z2rM5mHXA, LKML, Linux Memory Management List On 2023/7/7 9:47, Muchun Song wrote: > > >> On Jul 6, 2023, at 19:28, Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: >> >> MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove >> unneeded !CONFIG_MEMCG variant. >> >> Signed-off-by: Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> > > MEM_CGROUP_ID_MAX is also only used in mem_cgroup_alloc(), maybe you also > could move it from memcontrol.h to memcontrol.c. And define it as: > > #define MEM_CGROUP_ID_MAX ((1U << MEM_CGROUP_ID_SHIFT) - 1) > > I am not suggesting defining it as USHRT_MAX, because if someone changes > MEM_CGROUP_ID_SHIFT in the future, then MEM_CGROUP_ID_MAX will not updated > accordingly. Looks sensible to me. Do you suggest squashing above changes into the current patch or a separate patch is preferred? > > For this patch, LGTM. > > Reviewed-by: Muchun Song <songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org> Thanks for review and suggestion. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <61ce2910-f3de-cfb7-bdd3-546ade0cb6f3-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG [not found] ` <61ce2910-f3de-cfb7-bdd3-546ade0cb6f3-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> @ 2023-07-07 2:25 ` Muchun Song [not found] ` <52C942A9-29F7-473F-8674-6CB584F009BA-fxUVXftIFDnyG1zEObXtfA@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Muchun Song @ 2023-07-07 2:25 UTC (permalink / raw) To: Miaohe Lin Cc: Andrew Morton, Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt, cgroups-u79uwXL29TY76Z2rM5mHXA, LKML, Linux Memory Management List > On Jul 7, 2023, at 10:06, Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: > > On 2023/7/7 9:47, Muchun Song wrote: >> >> >>> On Jul 6, 2023, at 19:28, Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: >>> >>> MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove >>> unneeded !CONFIG_MEMCG variant. >>> >>> Signed-off-by: Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> >> >> MEM_CGROUP_ID_MAX is also only used in mem_cgroup_alloc(), maybe you also >> could move it from memcontrol.h to memcontrol.c. And define it as: >> >> #define MEM_CGROUP_ID_MAX ((1U << MEM_CGROUP_ID_SHIFT) - 1) >> >> I am not suggesting defining it as USHRT_MAX, because if someone changes >> MEM_CGROUP_ID_SHIFT in the future, then MEM_CGROUP_ID_MAX will not updated >> accordingly. > > Looks sensible to me. Do you suggest squashing above changes into the current patch > or a separate patch is preferred? I think it's better to squash. > >> >> For this patch, LGTM. >> >> Reviewed-by: Muchun Song <songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org> > > Thanks for review and suggestion. > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <52C942A9-29F7-473F-8674-6CB584F009BA-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>]
* Re: [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG [not found] ` <52C942A9-29F7-473F-8674-6CB584F009BA-fxUVXftIFDnyG1zEObXtfA@public.gmane.org> @ 2023-07-07 2:38 ` Miaohe Lin 0 siblings, 0 replies; 5+ messages in thread From: Miaohe Lin @ 2023-07-07 2:38 UTC (permalink / raw) To: Muchun Song Cc: Andrew Morton, Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt, cgroups-u79uwXL29TY76Z2rM5mHXA, LKML, Linux Memory Management List On 2023/7/7 10:25, Muchun Song wrote: > > >> On Jul 7, 2023, at 10:06, Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: >> >> On 2023/7/7 9:47, Muchun Song wrote: >>> >>> >>>> On Jul 6, 2023, at 19:28, Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: >>>> >>>> MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove >>>> unneeded !CONFIG_MEMCG variant. >>>> >>>> Signed-off-by: Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> >>> >>> MEM_CGROUP_ID_MAX is also only used in mem_cgroup_alloc(), maybe you also >>> could move it from memcontrol.h to memcontrol.c. And define it as: >>> >>> #define MEM_CGROUP_ID_MAX ((1U << MEM_CGROUP_ID_SHIFT) - 1) >>> >>> I am not suggesting defining it as USHRT_MAX, because if someone changes >>> MEM_CGROUP_ID_SHIFT in the future, then MEM_CGROUP_ID_MAX will not updated >>> accordingly. >> >> Looks sensible to me. Do you suggest squashing above changes into the current patch >> or a separate patch is preferred? > > I think it's better to squash. Will do if no objection. Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-07-07 2:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-06 11:28 [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG Miaohe Lin
2023-07-07 1:47 ` Muchun Song
[not found] ` <892B507C-CFE8-4792-BA5F-3C698290A8EE-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>
2023-07-07 2:06 ` Miaohe Lin
[not found] ` <61ce2910-f3de-cfb7-bdd3-546ade0cb6f3-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2023-07-07 2:25 ` Muchun Song
[not found] ` <52C942A9-29F7-473F-8674-6CB584F009BA-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>
2023-07-07 2:38 ` Miaohe Lin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox