let 4KSTACKS depend on EXPERIMENTAL (fwd)
PATCH 1/1 let 4KSTACKS depend on EXPERIMENTAL (fwd)
Hi Andrew,
I'd like to see the patch below included in 2.6.8 .
----- Forwarded message from Adrian Bunk <[email protected]> -----
Date: Sun, 1 Aug 2004 21:02:41 +0200
From: Adrian Bunk <[email protected]>
To: Nathan Scott <[email protected]>
Cc: Arjan van de Ven <[email protected]>,
"Jeffrey E. Hundstad" <[email protected]>, Linus Torvalds <[email protected]>, Andrew Morton <[email protected]>, Steve Lord <[email protected]>, [email protected], Cahya Wirawan <[email protected]>, [email protected]
Subject: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL
Quoted 4 lines · Nathan Scott
...
Quoted 2 lines · Adrian
2.6 is a stable kernel series used in production environments.
Quoted 8 lines
Quoted 2 lines
Regarding Linus' tree, it's IMHO the best solution to work around it this way until all issues are sorted out.
I'm not really convinced - the EXPERIMENTAL marking should be plenty of a deterent to folks in production environments. There are reports of stack overruns on other filesystems as well with 4KSTACKS, so doesn't seem worthwhile to me to do this just for XFS.
OK, below is a patch that only adds a dependency of 4KSTACKS on EXPERIMENTAL.
Considering that not all issues with 4kb stacks are currently corrected, this patch should IMHO go in 2.6.8 .
arch/i386/Kconfig renamed from arch/i386/Kconfig.old +2 -1
@@ -1474,7 +1474,8 @@ to solve problems without frame pointers. config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" + bool "Use 4Kb for kernel stacks instead of 8Kb (EXPERIMENTAL)" + depends on EXPERIMENTAL help If you say Y here the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread. This facilitates
-
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/
----- End forwarded message -----
Quoted 2 lines · Adrian Bunk
I'd like to see the patch below included in 2.6.8 .
I'm not seeing many (any) bug reports from this, and I'd generally prefer to keep people pushing down on the stack utilisation anyway.
So I'm disinclined to reduce 4k stacks' testing coverage...
Quoted 8 lines · Andrew Morton
Quoted 2 lines · Adrian Bunk
I'd like to see the patch below included in 2.6.8 .
I'm not seeing many (any) bug reports from this, and I'd generally prefer to keep people pushing down on the stack utilisation anyway.
So I'm disinclined to reduce 4k stacks' testing coverage...
There are still more than enough people with EXPERIMENTAL=y to give a decent testing coverage.
OTOH, at least XFS is known to have problems with 4kb stacks - and you don't want such problems to occur in production environments.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 2 lines · Adrian Bunk
OTOH, at least XFS is known to have problems with 4kb stacks - and you don't want such problems to occur in production environments.
So put && !4KSTACKS in the XFS configuration ?
Quoted 5 lines · Alan Cox
Quoted 2 lines · Adrian Bunk
OTOH, at least XFS is known to have problems with 4kb stacks - and you don't want such problems to occur in production environments.
So put && !4KSTACKS in the XFS configuration ?
I originally did this additionally (including moving 4KSTACKS above XFS).
But independent of the XFS problem, 4kb stacks currently risk additional breakage without real benefits for most users.
That sounds like a perfect place for using EXPERIMENTAL to me.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 6 lines · Adrian Bunk
Quoted 1 line
So put && !4KSTACKS in the XFS configuration ?
I originally did this additionally (including moving 4KSTACKS above XFS).
But independent of the XFS problem, 4kb stacks currently risk additional breakage without real benefits for most users.
Just before the Fedora kernel got 4K stacks (which was before mainline), in stress testing, I was hitting memory allocation bugs far sooner than I was hitting stack overflows, so I don't think this claim has any bearing on reality. It was far more commonplace for the kernel to struggle to find a free pair of contiguous pages under extreme load. And as already mentioned,
those overflows _can_ be hit with an 8KB stack too, you just have to
try harder.
The 'real benefits' you aren't seeing are lots of failing order-1 allocations under moderate to heavy load. You don't even need big iron boxes to see this, (in fact, its easier to hit this problem on smaller underpowered boxes).
Dave
Quoted 5 lines · Alan Cox
Quoted 2 lines · Adrian Bunk
OTOH, at least XFS is known to have problems with 4kb stacks - and you don't want such problems to occur in production environments.
So put && !4KSTACKS in the XFS configuration ?
The patch below does exactly this.
The 4KSTACKS option has to be moved for that it's asked before XFS in "make config".
diffstat output:
arch/i386/Kconfig | 18 +++++++++--------- fs/Kconfig | 1 + 2 files changed, 10 insertions(+), 9 deletions(-)
arch/i386/Kconfig renamed from arch/i386/Kconfig.old +9 -9
@@ -865,6 +865,15 @@ generate incorrect output with certain kernel constructs when -mregparm=3 is used. +config 4KSTACKS + bool "Use 4Kb for kernel stacks instead of 8Kb" + help + If you say Y here the kernel will use a 4Kb stacksize for the + kernel stack attached to each process/thread. This facilitates + running more threads on a system and also reduces the pressure + on the VM subsystem for higher order allocations. This option + will also use IRQ stacks to compensate for the reduced stackspace. + endmenu
@@ -1289,15 +1299,6 @@ If you don't debug the kernel, you can say N, but we may not be able to solve problems without frame pointers. -config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" - help - If you say Y here the kernel will use a 4Kb stacksize for the - kernel stack attached to each process/thread. This facilitates - running more threads on a system and also reduces the pressure - on the VM subsystem for higher order allocations. This option - will also use IRQ stacks to compensate for the reduced stackspace. - config X86_FIND_SMP_CONFIG bool depends on X86_LOCAL_APIC || X86_VOYAGER
fs/Kconfig renamed from fs/Kconfig.old +1 -0
@@ -294,6 +294,7 @@ config XFS_FS tristate "XFS filesystem support" + depends on (4KSTACKS=n || BROKEN) help XFS is a high performance journaling filesystem which originated on the SGI IRIX platform. It is completely multi-threaded, can