Parag Warudkar wrote:
On Dec 18, 2005, at 12:43 AM, Andi Kleen wrote:
You can catch the obvious ones, but the really hard ones
that only occur under high load in obscure exceptional
circumstances with large configurations and suitable nesting you won't.
These would be only found at real world users.
Yep, as it all depends on code complexity, some of these cases might
not be "errors" at all - instead for that kind of functionality they
might _require_ bigger stacks.
No complex problem ever requires a big stack. It may require a large amount
of memory - which can be allocated explicitly outside the stack.
If you have 64 bit machines common place and memory a lot cheaper I
don't see how it is beneficial to force smaller stack sizes without
giving consideration to the code complexity, architecture and
requirements.
(Solaris for example, seems to be going to have 16Kb kernel stacks on
64 bit machines.)
So, please let's leave stack size as an option for users to choose
and stop this 4Kb stack war. May be after a little rest I will start
another one demanding 16Kb stacks :)
I suggest a little experiment for you. Make a kernel module which do
nothing
except try to allocate 16k of _contigous_ kernel memory, and
printk whether it succeeded or failed before exiting. Have cron run that
every 5 minutes. After a few weeks of running this low-impact test on
a busy loaded server, look at statistics about how often the 16k allocation
worked - and how often it failed.
Whatever failure rate you get, expect the same failure rate for server
processes forking to handle new connections while running with 16k stacks.
Failing one out of a hundred times would probably not be tolerated
for a webserver, and I suspect the failure rate for this will be higher - if
the machine has a reasonable memory load and the usual fragmentation.
On the other hand, if you can surprise us about how this works very
well - then you have a strong argument!
Helge Hafting
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
