[2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Adrian Bunk]

Hi Andrew,

I'd like to see the patch below included in 2.6.8 .


----- Forwarded message from Adrian Bunk <bunk@fs.tum.de> -----

Date:	Sun, 1 Aug 2004 21:02:41 +0200
From: Adrian Bunk <bunk@fs.tum.de>
To: Nathan Scott <nathans@sgi.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	"Jeffrey E. Hundstad" <jeffrey.hundstad@mnsu.edu>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Steve Lord <lord@xfs.org>, linux-xfs@oss.sgi.com,
	Cahya Wirawan <cwirawan@email.archlab.tuwien.ac.at>,
	linux-kernel@vger.kernel.org
Subject: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL

On Fri, Jul 30, 2004 at 08:30:40AM +1000, Nathan Scott wrote:
>...
> Adrian wrote:
> > 2.6 is a stable kernel series used in production environments.
> > 
> > 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 .


Signed-off-by: Adrian Bunk <bunk@fs.tum.de>

--- linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig.old	2004-08-01 20:59:02.000000000 +0200
+++ linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig	2004-08-01 20:59:46.000000000 +0200
@@ -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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> 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...

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Alan Cox]

On Maw, 2004-08-03 at 01:45, Adrian Bunk wrote:
> 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 ?

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Adrian Bunk]

On Mon, Aug 02, 2004 at 04:28:46PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > 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

-- 

       "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 Seed

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Adrian Bunk]

On Tue, Aug 03, 2004 at 12:56:01AM +0100, Alan Cox wrote:
> On Maw, 2004-08-03 at 01:45, Adrian Bunk wrote:
> > 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

-- 

       "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 Seed

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Dave Jones]

On Tue, Aug 03, 2004 at 03:13:39PM +0200, Adrian Bunk wrote:

 > > 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

Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd)

[Adrian Bunk]

On Tue, Aug 03, 2004 at 12:56:01AM +0100, Alan Cox wrote:
> On Maw, 2004-08-03 at 01:45, Adrian Bunk wrote:
> > 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(-)


Signed-off-by: Adrian Bunk <bunk@fs.tum.de>

--- linux-2.6.8-rc2-full/arch/i386/Kconfig.old	2004-07-20 21:00:32.000000000 +0200
+++ linux-2.6.8-rc2-full/arch/i386/Kconfig	2004-07-20 21:03:30.000000000 +0200
@@ -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
--- linux-2.6.8-rc2-full/fs/Kconfig.old	2004-07-20 21:04:02.000000000 +0200
+++ linux-2.6.8-rc2-full/fs/Kconfig	2004-07-20 21:04:25.000000000 +0200
@@ -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