Ingo didn't say anything at all like that.
Ingo said that 2.0.x had problems operating with a 4kB stack. We had
issues with stack frames being big with various SCSI device drivers, and
that together with certain filesystems having a big stack (umsdos was the
worst), led to various very-hard-to-explain problems for some people.
We solved it by making sure that some of the worst offenders were fixed,
but the point is that 4kB of stack is not all that much.
In 2.1.x, we have a _very_ clever scheme for the "current" pointer, that
speeds up both SMP and UP, and makes them both behave exactly the same
way. However, in order to do that clever scheme, the "stack area" was
expanded to not only contain the stack, but also contain the "current"
task structure.
This had the advantage of generally speeding things up, but it made a lot
of other sense too - for example you now only need one allocation for both
stack and "struct task_struct", and so "fork()" was faster.
However, "struct task_struct" is fo a non-negligible size, as it has to
have all the process information, and trying to fit both the stack and
that into 4kB was simply not an option. So we expanded the common area to
be 8kB - it's not that the stack grew, it's just that we needed to fit
other things than the stack in the same area.
The fact that the "struct task_struct" is smaller than 4kB and the usable
stack area grew is a side effect, it's not the reason. 2.1.x does not need
any more stack than 2.0.x needed.
vmalloc() is not acceptable.
Getting 8kB allocations shouldn't be too hard - it's just that the current
mm/page_alloc.c gives up a bit too easily as a backlash against it never
giving up at all in certain 2.1.x kernels. It's a balancing issue, and
getting rid of the 8kB allocation is not the answer.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html