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