Re: [PATCH v2 0/8] scheduler tinification

[Ingo Molnar]

* Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> 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