Messages in this thread | | | Date | Wed, 7 Jun 2017 18:00:10 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v2 0/8] scheduler tinification |
| |
* 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
| |