[v3,0/8] sched: Move a series of sysctls starting with sys/kernel/sched_*

Message

Zhen Ni Feb. 15, 2022, 11:45 a.m. UTC

move a series of sysctls starting with sys/kernel/sched_* and use the
new register_sysctl_init() to register the sysctl interface.

Zhen Ni (8):
  sched: Move child_runs_first sysctls to fair.c
  sched: Move schedstats sysctls to core.c
  sched: Move rt_period/runtime sysctls to rt.c
  sched: Move deadline_period sysctls to deadline.c
  sched: Move rr_timeslice sysctls to rt.c
  sched: Move uclamp_util sysctls to core.c
  sched: Move cfs_bandwidth_slice sysctls to fair.c
  sched: Move energy_aware sysctls to topology.c

 include/linux/sched/sysctl.h | 41 ---------------
 kernel/rcu/rcu.h             |  2 +
 kernel/sched/core.c          | 69 ++++++++++++++++++-------
 kernel/sched/deadline.c      | 42 +++++++++++++---
 kernel/sched/fair.c          | 32 +++++++++++-
 kernel/sched/rt.c            | 56 +++++++++++++++++++--
 kernel/sched/sched.h         |  7 +++
 kernel/sched/topology.c      | 25 +++++++++-
 kernel/sysctl.c              | 97 ------------------------------------
 9 files changed, 201 insertions(+), 170 deletions(-)

Comments

Luis Chamberlain Feb. 17, 2022, 7:51 a.m. UTC | #1

On Tue, Feb 15, 2022 at 07:45:56PM +0800, Zhen Ni wrote:
> move a series of sysctls starting with sys/kernel/sched_* and use the
> new register_sysctl_init() to register the sysctl interface.

Peter, Andrew,

I'm starting to get more sysctl patches under kernel/ other than the
scheduler. To avoid low quality patches, try to see proactively what
conflicts may lie ahead, ensure everything is applies on linux-next,
and to ensure all this gets baked through 0-day for a while, I'm
going to shove all pending patches into a sysctl-next branch based on
Linus' tree.

I think it doesn't make sense now to just say, do this for sched for one
release. I think we need to get these more widely tested in a faster
way, and to get conflicts ironed out faster too.

Are you folks OK if say Stephen adds a sysctl-next for linux-next so
we can beat on these there too?

FWIW queued on sysctl-next [0].

[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-next

  Luis

Andrew Morton Feb. 18, 2022, 2:52 a.m. UTC | #2

On Wed, 16 Feb 2022 23:51:08 -0800 Luis Chamberlain <[e-mail]> wrote:

> Are you folks OK if say Stephen adds a sysctl-next for linux-next so
> we can beat on these there too?

Sure.  I just sent you a couple which I've collected.

Luis Chamberlain Feb. 18, 2022, 6:21 p.m. UTC | #3

On Thu, Feb 17, 2022 at 06:52:38PM -0800, Andrew Morton wrote:
> On Wed, 16 Feb 2022 23:51:08 -0800 Luis Chamberlain <[e-mail]> wrote:
> 
> > Are you folks OK if say Stephen adds a sysctl-next for linux-next so
> > we can beat on these there too?
> 
> Sure.  I just sent you a couple which I've collected.

OK thanks! I've merged those into sysctl-next [0]

Stephen,

Can you add it to the set of trees you pull? I'll send a patch to add
this to MAINTAINERS too then.

[0] git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git sysctl-next

  Luis

Stephen Rothwell Feb. 20, 2022, 12:05 a.m. UTC | #4

Hi Luis,

On Fri, 18 Feb 2022 10:21:56 -0800 Luis Chamberlain <[e-mail]> wrote:
>
> On Thu, Feb 17, 2022 at 06:52:38PM -0800, Andrew Morton wrote:
> > On Wed, 16 Feb 2022 23:51:08 -0800 Luis Chamberlain <[e-mail]> wrote:
> >   
> > > Are you folks OK if say Stephen adds a sysctl-next for linux-next so
> > > we can beat on these there too?  
> > 
> > Sure.  I just sent you a couple which I've collected.  
> 
> OK thanks! I've merged those into sysctl-next [0]
> 
> Stephen,
> 
> Can you add it to the set of trees you pull? I'll send a patch to add
> this to MAINTAINERS too then.
> 
> [0] git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git sysctl-next

Added from whenever the next linux-next tree gets done.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.