All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Zhen Ni <nizhen@uniontech.com>
Cc: mingo@redhat.com, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, mcgrof@kernel.org,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] sched: move rr_timeslice sysctls to rt.c
Date: Fri, 11 Feb 2022 12:51:14 +0100	[thread overview]
Message-ID: <20220211115114.GU23216@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20220210060831.26689-1-nizhen@uniontech.com>

On Thu, Feb 10, 2022 at 02:08:31PM +0800, Zhen Ni wrote:
> move rr_timeslice sysctls to rt.c and use the new
> register_sysctl_init() to register the sysctl interface.
> 
> Signed-off-by: Zhen Ni <nizhen@uniontech.com>

OK, I've had it with this nonsense. Can you *please* redo all of sched
such that:

 - In the Subject:, the first letter after the subsystem prefix (sched:)
   is capitalized.
 - the lot actually applies to tip/sched/core (so far not a single one
   of these patches applied without needing -- mostly trivial --
   fixups).
 - Do obvious cleanups.. see below.
 - Don't have more than a single *sysctl_init() per .c file.
 - It's a full series that does all instead of random little patches
   that conflict with one another when applied out of turn.

> ---
>  include/linux/sched/sysctl.h |  3 ---
>  kernel/sched/rt.c            | 28 ++++++++++++++++++++++++++--
>  kernel/sysctl.c              |  7 -------
>  3 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
> index d416d8f45186..f6466040883c 100644
> --- a/include/linux/sched/sysctl.h
> +++ b/include/linux/sched/sysctl.h
> @@ -45,11 +45,8 @@ extern unsigned int sysctl_sched_uclamp_util_min_rt_default;
>  extern unsigned int sysctl_sched_autogroup_enabled;
>  #endif
>  
> -extern int sysctl_sched_rr_timeslice;
>  extern int sched_rr_timeslice;

Why leave sched_rr_timeslice here? It doesn't belong here.


> +#ifdef CONFIG_SYSCTL
> +static struct ctl_table sched_rr_sysctls[] = {
> +	{
> +		.procname       = "sched_rr_timeslice_ms",
> +		.data           = &sysctl_sched_rr_timeslice,
> +		.maxlen         = sizeof(int),
> +		.mode           = 0644,
> +		.proc_handler   = sched_rr_handler,
> +	},
> +	{}
> +};
> +
> +static void __init sched_rr_sysctl_init(void)
> +{
> +	register_sysctl_init("kernel", sched_rr_sysctls);
> +}
> +#else
> +#define sched_rr_sysctl_init() do { } while (0)
> +#endif
> +
>  static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun);
>  
>  struct rt_bandwidth def_rt_bandwidth;
> @@ -2471,6 +2494,7 @@ void __init init_sched_rt_class(void)
>  		zalloc_cpumask_var_node(&per_cpu(local_cpu_mask, i),
>  					GFP_KERNEL, cpu_to_node(i));
>  	}
> +	sched_rr_sysctl_init();
>  }

When I combine this with: patches/zhen_ni-sched-move_rt_period_runtime_sysctls_to_rt_c.patch

That ends up as:

@@ -2471,6 +2535,8 @@ void __init init_sched_rt_class(void)
                zalloc_cpumask_var_node(&per_cpu(local_cpu_mask, i),
                                        GFP_KERNEL, cpu_to_node(i));
        }
+       sched_rt_sysctl_init();
+       sched_rr_sysctl_init();
 }
 #endif /* CONFIG_SMP */

Like srsly?


So I've dropped the whole lot I had:

patches/zhen_ni-sched-move_energy_aware_sysctls_to_topology_c.patch
patches/zhen_ni-sched-move_cfs_bandwidth_slice_sysctls_to_fair_c.patch
patches/zhen_ni-sched-move_uclamp_util_sysctls_to_core_c.patch
patches/zhen_ni-sched-move_schedstats_sysctls_to_core_c.patch
patches/zhen_ni-sched-move_deadline_period_sysctls_to_deadline_c.patch
patches/zhen_ni-sched-move_rt_period_runtime_sysctls_to_rt_c.patch
patches/zhen_ni-sched-move_rr_timeslice_sysctls_to_rt_c.patch

And I expect a single coherent series or I'll forgo all this.

  reply	other threads:[~2022-02-11 11:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10  6:08 [PATCH] sched: move rr_timeslice sysctls to rt.c Zhen Ni
2022-02-11 11:51 ` Peter Zijlstra [this message]
2022-02-11 18:23   ` Luis Chamberlain

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=20220211115114.GU23216@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nizhen@uniontech.com \
    --cc=vincent.guittot@linaro.org \
    /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.