linux-kernel - Re: [PATCH v2 0/8] scheduler tinification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.20.1706111051130.29475@knanqh.ubzr>
Date:   Sun, 11 Jun 2017 11:26:11 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Ingo Molnar <mingo@...nel.org>
cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 0/8] scheduler tinification

On Sun, 11 Jun 2017, Ingo Molnar wrote:

> 
> * Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> 
> > If you want to pick only those patches for now then please be my guest. 
> > At least the first two patches of the series should be mergeable without 
> > even a doubt.
> 
> That's a strawman argument - I was reacting to the combined effect of your series:
> 
>  > > >  23 files changed, 3190 insertions(+), 2897 deletions(-)

As I mentioned, the bulk of that count comes from moving rt and dl code 
out of sched/core.c into their respective .c files:


    sched/deadline: move dl related code out of sched/core.c
    
    ... to sched/deadline.c. This helps making sched/core.c smaller and
    hopefully easier to understand and maintain. This also will help
    configuring the deadline scheduling class out of the kernel build.
    
    Signed-off-by: Nicolas Pitre <nico@...aro.org>

 kernel/sched/core.c     | 335 +----------------------------------------
 kernel/sched/deadline.c | 336 ++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/sched.h    |  14 ++
 3 files changed, 356 insertions(+), 329 deletions(-)


    sched/rt: move rt related code out of sched/core.c
    
    ... to sched/rt.c. This helps making sched/core.c smaller and hopefully
    easier to understand and maintain. This also will make it easier to
    configure the realtime scheduling class out of the kernel build.
    
    Signed-off-by: Nicolas Pitre <nico@...aro.org>

 kernel/sched/core.c  | 315 ---------------------------------------------
 kernel/sched/rt.c    | 310 ++++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/sched.h |   5 +
 3 files changed, 315 insertions(+), 315 deletions(-)

I also untangled the futex code so the PI support is gathered in a file 
of its own:


    futex: make PI support optional
    
    Split out the priority inheritance support to a file of its own
    to make futex.c easier to understand and, hopefully, to maintain.
    This also makes it possible to compile out the PI support when RT
    task support is not available.
    
    Signed-off-by: Nicolas Pitre <nico@...aro.org>

 include/linux/futex.h |    7 +-
 init/Kconfig          |    7 +-
 kernel/futex.c        | 2829 ++++++++++---------------------------------
 kernel/futex_pi.c     | 1563 ++++++++++++++++++++++++
 4 files changed, 2233 insertions(+), 2173 deletions(-)

Granted I made a mistake in this last description above. It should have 
said "RT mutex support" instead of "RT task support". But those 3 
patches are making the code easier to understand I'd say.

> A subset of the patches might be fine and note that in fact I already picked a 
> patch from your series that made sense, I committed this patch of yours three days 
> ago:
> 
>   f5832c1998af: sched/core: Omit building stop_sched_class when !SMP

Good. That was patch #2/8.  Why did you skip over #1/8 "cpuset/sched: 
cpuset makes sense for SMP only"? It is the same kind of simple cleanup 
as the one you did apply.

> I'll pick others as well as long as they don't complicate the code. Please send a 
> revised series that only does unambiguous complexity reduction/cleanups.

Tell me from the above which patches would qualify and I'll repost them.


Nicolas