Re: [PATCH v2 0/8] scheduler tinification

From	Ingo Molnar <mingo@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH v2 0/8] scheduler tinification
Date	2017-06-07 18:10 +0200
Message-ID	<tPLGV-rD-3@gated-at.bofh.it> (permalink)
References	<tPw5b-71w-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

* Nicolas Pitre <nicolas.pitre@linaro.org> wrote:

> Many embedded systems don't need the full scheduler support. Most of the
> time, user space is tightly controlled and many of the scheduler facilities
> are simply unused.

Sorry, NAK:

>  23 files changed, 3190 insertions(+), 2897 deletions(-)

That's a lot of extra code plus churn for a code base that is already pretty
#ifdef heavy.

Also, the savings are marginal, even with significant functionality disabled:

>   text    data     bss     dec     hex filename
>  28623    3404     128   32155    7d9b kernel/sched/built-in.o
>
> With this series and dl and rt classes disabled:
>
>   text    data     bss     dec     hex filename
>  20734    3334      40   24108    5e2c kernel/sched/built-in.o

With 1GHz + 1GB RAM SoCs being well below $10 in bulk we worry about code 
complexity, predictability, testability, behavioral and ABI uniformity a lot more 
than about the last 10-20k of kernel text footprint...

So I think the 'tiny' efforts are fundamentally misguided and are shooting for an 
ever shrinking market of RAM/ROM starved products whose share is shrinking every 
month.

We want to _remove_ kernel options and reduce complexity, not increase it.

So unless there's convincing counter arguments, or Linus overrules me, this NAK is 
pretty firm.

I'd love to see scheduler complexity reduction patches though, the "CPP count" of 
the scheduler code base is pretty damn high:

  triton:~/tip> git grep -h '^#[^ ]' kernel/sched/  | cut -d' ' -f1 | sort | uniq -c | sort -n | tail -10
      2 #ifdef  CONFIG_SCHED_DEBUG
      4 #endif  /*
     19 #if
     26 #ifndef
     27 #undef
     97 #else
    161 #define
    199 #include
    317 #ifdef
    361 #endif

Thanks,

	Ingo

Thread

[PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-07 01:30 +0200
  [PATCH v2 8/8] sched/rt: make it configurable Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-07 01:30 +0200
  [PATCH v2 1/8] cpuset/sched: cpuset makes sense for SMP only Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-07 01:50 +0200
  Re: [PATCH v2 0/8] scheduler tinification Ingo Molnar <mingo@kernel.org> - 2017-06-07 18:10 +0200
    Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-07 19:10 +0200
      Re: [PATCH v2 0/8] scheduler tinification Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-07 21:00 +0200
        Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-07 23:20 +0200
          Re: [PATCH v2 0/8] scheduler tinification Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-08 00:00 +0200
      Re: [PATCH v2 0/8] scheduler tinification Ingo Molnar <mingo@kernel.org> - 2017-06-08 10:00 +0200
        Re: [PATCH v2 0/8] scheduler tinification Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-08 20:20 +0200
        Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-08 22:20 +0200
          Re: [PATCH v2 0/8] scheduler tinification Ingo Molnar <mingo@kernel.org> - 2017-06-11 11:30 +0200
            Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-11 17:30 +0200
          Re: [PATCH v2 0/8] scheduler tinification Ingo Molnar <mingo@kernel.org> - 2017-06-11 11:50 +0200
            Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-11 18:50 +0200
              Re: [PATCH v2 0/8] scheduler tinification Ingo Molnar <mingo@kernel.org> - 2017-06-13 09:20 +0200
                Re: [PATCH v2 0/8] scheduler tinification Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-06-13 14:30 +0200

csiph-web