Cc: Willy Tarreau <w@...>, Mark Lord <lkml@...>, Adrian Bunk <bunk@...>, Alan Cox <alan@...>, Shawn Bohrer <shawn.bohrer@...>, Ingo Molnar <mingo@...>, Andrew Morton <akpm@...>, Linux Kernel Mailing List <linux-kernel@...>, Arjan van de Ven <arjan@...>, Thomas Gleixner <tglx@...>
Sure but I don't think they're x86 embedded people. Right now there
are very little x86 SOCs if any (iirc there is only some obscure rise
core) and future SOCs will likely have more RAM.
Anyways I don't have a problem to give these people any special options
they need to do whatever they want. I just object to changing the
default options on important architectures to force people in completely
different setups to do part of their testing.
Whether they care enough to actually spend
I was just objecting to your claim that small stack implies smaller
cache foot print. Smaller stacks rarely give you smaller cache foot
print in my kernel coding experience:
First some stack is always safety and in practice unused. It won't
be in cache.
Then typically standard kernel stack pigs are just too large
buffers on the stack which are not fully used. These also
don't have much cache foot print.
Or if you have a complicated call stack the typical fix
is to move parts of it into another thread. But that doesn't
give you less cache footprint because the cache foot print
is just in someone else's stack. In fact you'll likely
have slightly more cache foot print from that due to the
context of the other thread.
In theory if you e.g. convert a recursive algorithm
to iterative you might save some cache foot print, but I don't
think that really happens in kernel code.
-Andi
--
