On Tuesday 06 September 2005 08:39, Denis Vlasenko wrote: > I think one of the reasons is: > > "No matter how big stack is, there are always careless > code which can overflow it. 4k, 8k, 64k (hypotetically), > we still must keep stack size in mind when coding. > > So, since we already are writing stack size aware code, > why not pick minimum realistically working stack size? Looks > like we can make 4k stack work, and it's naturally smallest > sensible (and in fact easiest to allocate/manage) stack for i386. > So be it, let's use 4k."
Better engineering is to take the minimum size and then add some safety margin. Running with the minimum only is ok when you have the infrastructure to prove maximum stack usage, but Linux is far too complex for that. In general running with no safety margin is not a good idea. BTW your minimum doesn't seem to be everybody's minimum - everytime you see someone advocating the smallest stacks they go "it's fine for us, but don't use A, B, C, D" (and I expect these lists to get longer with more experience). The trend in Linux clearly seems to be towards more complex code. While that is not always a good thing but it seems to be unstoppable (everybody wants their favourite features and the merging machinery is well oiled and in full action). And doing all that will need more stack space over time so shrinking is clearly the wrong strategic direction. At some point we undoubtedly will need to increase it further, the logical point would be when Linux switches to larger softpage sizes. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
