| Message ID | 20220908072531.87916-1-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | sched: Move numa_balancing sysctls to its own file | expand |
On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: > The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing > are part of sched, move them to its own file. > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> There is quite a bit of random cleanup on each kernel release for sysctls to do things like what you just did. Because of this it has its own tree to help avoid conflicts. Can you base your patches on the sysctl-testing branch here and re-submit: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing If testing goes fine, then I'd move this to sysctl-next which linux-next picks up for yet more testing. Are scheduling folks OK with this patch and me picking it up on the sysctl-next tree if all tests are a go? Luis
On 2022/9/9 8:06, Luis Chamberlain wrote: > On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: >> The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing >> are part of sched, move them to its own file. >> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > There is quite a bit of random cleanup on each kernel release > for sysctls to do things like what you just did. Because of this it has its > own tree to help avoid conflicts. Can you base your patches on the > sysctl-testing branch here and re-submit: Found this when reading memory tiering code，sure to re-submit based your branch, thanks. > > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing > > If testing goes fine, then I'd move this to sysctl-next which linux-next > picks up for yet more testing. > > Are scheduling folks OK with this patch and me picking it up on the > sysctl-next tree if all tests are a go? > > Luis > .
On 2022/9/9 9:46, Kefeng Wang wrote: > > On 2022/9/9 8:06, Luis Chamberlain wrote: >> On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: >>> The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing >>> are part of sched, move them to its own file. >>> >>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> There is quite a bit of random cleanup on each kernel release >> for sysctls to do things like what you just did. Because of this it >> has its >> own tree to help avoid conflicts. Can you base your patches on the >> sysctl-testing branch here and re-submit: > > Found this when reading memory tiering code，sure to re-submit based > your branch, > > thanks. > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing >> Hi Luis，the numa_balancing_promote_rate_limit_MBps from commit 1db91dd846e0 “memory tiering: rate limit NUMA migration throughput”only on linux-next（from mm repo）， 1）only send sysctl_numa_balancing changes based on your branch or 2）queued this patch from mm repo if no objection， Cc'ed Andrew Which one do your like, or other options, thanks. >> >> If testing goes fine, then I'd move this to sysctl-next which linux-next >> picks up for yet more testing. >> >> Are scheduling folks OK with this patch and me picking it up on the >> sysctl-next tree if all tests are a go? >> >> Luis >> .
On Fri, Sep 09, 2022 at 11:37:41AM +0800, Kefeng Wang wrote: > > On 2022/9/9 9:46, Kefeng Wang wrote: > > > > On 2022/9/9 8:06, Luis Chamberlain wrote: > > > On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: > > > > The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing > > > > are part of sched, move them to its own file. > > > > > > > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > > > There is quite a bit of random cleanup on each kernel release > > > for sysctls to do things like what you just did. Because of this it > > > has its > > > own tree to help avoid conflicts. Can you base your patches on the > > > sysctl-testing branch here and re-submit: > > > > Found this when reading memory tiering code，sure to re-submit based > > your branch, > > > > thanks. > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing > > > > Hi Luis，the numa_balancing_promote_rate_limit_MBps from commit 1db91dd846e0 > “memory tiering: rate limit NUMA migration throughput”only on > linux-next（from mm repo）， > > 1）only send sysctl_numa_balancing changes based on your branch > or > > 2）queued this patch from mm repo if no objection， Cc'ed Andrew > > Which one do your like, or other options, thanks. 2) as that would give more testing to the new code as well. We can deal with merge conflicts on my tree later. Luis
On 2022/9/10 3:44, Luis Chamberlain wrote: > On Fri, Sep 09, 2022 at 11:37:41AM +0800, Kefeng Wang wrote: >> On 2022/9/9 9:46, Kefeng Wang wrote: >>> On 2022/9/9 8:06, Luis Chamberlain wrote: >>>> On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: >>>>> The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing >>>>> are part of sched, move them to its own file. >>>>> >>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >>>> There is quite a bit of random cleanup on each kernel release >>>> for sysctls to do things like what you just did. Because of this it >>>> has its >>>> own tree to help avoid conflicts. Can you base your patches on the >>>> sysctl-testing branch here and re-submit: >>> Found this when reading memory tiering code，sure to re-submit based >>> your branch, >>> >>> thanks. >>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing >>>> >> Hi Luis，the numa_balancing_promote_rate_limit_MBps from commit 1db91dd846e0 >> “memory tiering: rate limit NUMA migration throughput”only on >> linux-next（from mm repo）， >> >> 1）only send sysctl_numa_balancing changes based on your branch >> or >> >> 2）queued this patch from mm repo if no objection， Cc'ed Andrew >> >> Which one do your like, or other options, thanks. > 2) as that would give more testing to the new code as well. We can deal > with merge conflicts on my tree later. Thanks Luis. Hi Andrew, could you help to pick it up to your tree :) > > Luis > .
Hi Luis and Andrew， As the c6833e10008f （"memory tiering: rate limit NUMA migration throughput"), has been merged into linux v6.1-rc1, there is no conflict about this patch, could anyone help to pick it up, thanks. On 2022/9/10 3:44, Luis Chamberlain wrote: > On Fri, Sep 09, 2022 at 11:37:41AM +0800, Kefeng Wang wrote: >> On 2022/9/9 9:46, Kefeng Wang wrote: >>> On 2022/9/9 8:06, Luis Chamberlain wrote: >>>> On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: >>>>> The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing >>>>> are part of sched, move them to its own file. >>>>> >>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >>>> There is quite a bit of random cleanup on each kernel release >>>> for sysctls to do things like what you just did. Because of this it >>>> has its >>>> own tree to help avoid conflicts. Can you base your patches on the >>>> sysctl-testing branch here and re-submit: >>> Found this when reading memory tiering code，sure to re-submit based >>> your branch, >>> >>> thanks. >>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing >>>> >> Hi Luis，the numa_balancing_promote_rate_limit_MBps from commit 1db91dd846e0 >> “memory tiering: rate limit NUMA migration throughput”only on >> linux-next（from mm repo）， >> >> 1）only send sysctl_numa_balancing changes based on your branch >> or >> >> 2）queued this patch from mm repo if no objection， Cc'ed Andrew >> >> Which one do your like, or other options, thanks. > 2) as that would give more testing to the new code as well. We can deal > with merge conflicts on my tree later. > Luis > .
On Mon, Nov 21, 2022 at 11:09:27AM +0800, Kefeng Wang wrote: > Hi Luis and Andrew， > > As the c6833e10008f （"memory tiering: rate limit NUMA migration > throughput"), > could > > anyone help to pick it up, thanks. Queued up now on sysctl-next, thanks! BTW if you do the cleanup on kernel/sysctl.c for the rest of CONFIG_NUMA It would be appreciated. :) Luis
On 2022/11/21 12:58, Luis Chamberlain wrote: > On Mon, Nov 21, 2022 at 11:09:27AM +0800, Kefeng Wang wrote: >> Hi Luis and Andrew， >> >> As the c6833e10008f （"memory tiering: rate limit NUMA migration >> throughput"), >> could >> >> anyone help to pick it up, thanks. > Queued up now on sysctl-next, thanks! > > BTW if you do the cleanup on kernel/sysctl.c for the rest of CONFIG_NUMA > It would be appreciated. :) Will check it，many thanks. > > Luis > .
On Thu, Sep 08, 2022 at 05:06:03PM -0700, Luis Chamberlain wrote: > On Thu, Sep 08, 2022 at 03:25:31PM +0800, Kefeng Wang wrote: > > The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing > > are part of sched, move them to its own file. > > > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > > There is quite a bit of random cleanup on each kernel release > for sysctls to do things like what you just did. Because of this it has its > own tree to help avoid conflicts. Can you base your patches on the > sysctl-testing branch here and re-submit: > > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-testing > > If testing goes fine, then I'd move this to sysctl-next which linux-next > picks up for yet more testing. > > Are scheduling folks OK with this patch and me picking it up on the > sysctl-next tree if all tests are a go? Yeah, think so, it just moves stuff around a bit. ACK.
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h index 303ee7dd0c7e..9431b7e00047 100644 --- a/include/linux/sched/sysctl.h +++ b/include/linux/sched/sysctl.h @@ -27,12 +27,8 @@ enum sched_tunable_scaling { #ifdef CONFIG_NUMA_BALANCING extern int sysctl_numa_balancing_mode; -extern unsigned int sysctl_numa_balancing_promote_rate_limit; #else #define sysctl_numa_balancing_mode 0 #endif -int sysctl_numa_balancing(struct ctl_table *table, int write, void *buffer, - size_t *lenp, loff_t *ppos); - #endif /* _LINUX_SCHED_SYSCTL_H */ diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b60422300af6..677225b71538 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4407,7 +4407,7 @@ static void reset_memory_tiering(void) } } -int sysctl_numa_balancing(struct ctl_table *table, int write, +static int sysctl_numa_balancing(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos) { struct ctl_table t; @@ -4534,6 +4534,17 @@ static struct ctl_table sched_core_sysctls[] = { .proc_handler = sysctl_sched_uclamp_handler, }, #endif /* CONFIG_UCLAMP_TASK */ +#ifdef CONFIG_NUMA_BALANCING + { + .procname = "numa_balancing", + .data = NULL, /* filled in by handler */ + .maxlen = sizeof(unsigned int), + .mode = 0644, + .proc_handler = sysctl_numa_balancing, + .extra1 = SYSCTL_ZERO, + .extra2 = SYSCTL_FOUR, + }, +#endif /* CONFIG_NUMA_BALANCING */ {} }; static int __init sched_core_sysctl_init(void) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index cf3300b1a1d2..ff37620bdfbe 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -178,6 +178,11 @@ int __weak arch_asym_cpu_priority(int cpu) static unsigned int sysctl_sched_cfs_bandwidth_slice = 5000UL; #endif +#ifdef CONFIG_NUMA_BALANCING +/* Restrict the NUMA promotion throughput (MB/s) for each target node. */ +static unsigned int sysctl_numa_balancing_promote_rate_limit = 65536; +#endif + #ifdef CONFIG_SYSCTL static struct ctl_table sched_fair_sysctls[] = { { @@ -197,6 +202,16 @@ static struct ctl_table sched_fair_sysctls[] = { .extra1 = SYSCTL_ONE, }, #endif +#ifdef CONFIG_NUMA_BALANCING + { + .procname = "numa_balancing_promote_rate_limit_MBps", + .data = &sysctl_numa_balancing_promote_rate_limit, + .maxlen = sizeof(unsigned int), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = SYSCTL_ZERO, + }, +#endif /* CONFIG_NUMA_BALANCING */ {} }; @@ -1094,9 +1109,6 @@ unsigned int sysctl_numa_balancing_scan_delay = 1000; /* The page with hint page fault latency < threshold in ms is considered hot */ unsigned int sysctl_numa_balancing_hot_threshold = MSEC_PER_SEC; -/* Restrict the NUMA promotion throughput (MB/s) for each target node. */ -unsigned int sysctl_numa_balancing_promote_rate_limit = 65536; - struct numa_group { refcount_t refcount; diff --git a/kernel/sysctl.c b/kernel/sysctl.c index f10a610aa834..2ea3bf603b89 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -1631,25 +1631,6 @@ int proc_do_static_key(struct ctl_table *table, int write, } static struct ctl_table kern_table[] = { -#ifdef CONFIG_NUMA_BALANCING - { - .procname = "numa_balancing", - .data = NULL, /* filled in by handler */ - .maxlen = sizeof(unsigned int), - .mode = 0644, - .proc_handler = sysctl_numa_balancing, - .extra1 = SYSCTL_ZERO, - .extra2 = SYSCTL_FOUR, - }, - { - .procname = "numa_balancing_promote_rate_limit_MBps", - .data = &sysctl_numa_balancing_promote_rate_limit, - .maxlen = sizeof(unsigned int), - .mode = 0644, - .proc_handler = proc_dointvec_minmax, - .extra1 = SYSCTL_ZERO, - }, -#endif /* CONFIG_NUMA_BALANCING */ { .procname = "panic", .data = &panic_timeout,
The sysctl_numa_balancing_promote_rate_limit and sysctl_numa_balancing are part of sched, move them to its own file. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- include/linux/sched/sysctl.h | 4 ---- kernel/sched/core.c | 13 ++++++++++++- kernel/sched/fair.c | 18 +++++++++++++++--- kernel/sysctl.c | 19 ------------------- 4 files changed, 27 insertions(+), 27 deletions(-)