[lkml]   [2005]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.6 patch] i386: always use 4k/4k stacks

> Btw., has anyone yet *measured* maximum stack usage for some weeks on several
> machines, e.g. desktop system with one NIC, reiserfs; server with several
> NICs, stacked device-mapper targets, fiber channel, appletalk...; web server
> with SQL database running on it etc?

partially, see below

> Right now I have the impression that the 4k stack flamewars base on make
> checkstack output, waiting for bugreports and other guesswork. Removing the
> safety net on such a basis is just *very bad engineering*.

your impression is wrong.

the kernel has a stack overflow detector, which checks at irq entry time
if the stack is "rather high" (7kb into the stack on a 8kb stack, 3.5kb
on a 4k stack). When this warning hits there's still runway left (like
12.5 percent), but lets say the end becomes in sight. If the stack usage
would be really tight, this "early warning" detector would be hitting a
lot of people, right? Well the good news is that it isn't being hit in
the distributions that use 4Kb stacks (at least the fedora releases and
RHEL, maybe others), with a few exceptions related to XFS use several
months ago (which got fixed since).

While this isn't a measure of how deep things ACTUALLY go, it's a
measure that they don't go past the 3.5Kb limit, let alone go past 4Kb

In addition someone did a chain analysis (which no doubt isn't 100%
complete but still a pretty good effort) and that didn't show major
problems either.

The guesswork in this thread is all from the people on the other side of
the argument, with lots fear and doubt but with no data ;)

(and the "safety net" is a bit of misnomer, since it's not really safe,
just "statistically different" if the shit hits the fan)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-18 12:28    [W:0.058 / U:1.532 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site