All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@fs.tum.de>
To: "Jeffrey E. Hundstad" <jeffrey.hundstad@mnsu.edu>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Steve Lord <lord@xfs.org>
Cc: linux-xfs@oss.sgi.com, xfs-masters@oss.sgi.com, nathans@sgi.com,
	Cahya Wirawan <cwirawan@email.archlab.tuwien.ac.at>,
	linux-kernel@vger.kernel.org
Subject: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL and XFS on 4KSTACKS=n
Date: Tue, 20 Jul 2004 21:50:12 +0200	[thread overview]
Message-ID: <20040720195012.GN14733@fs.tum.de> (raw)
In-Reply-To: <40FD2E99.20707@mnsu.edu>

On Tue, Jul 20, 2004 at 09:39:21AM -0500, Jeffrey E. Hundstad wrote:
> Steve Lord wrote:
> 
> >Don't use 4K stacks and XFS. What you hit here is a path where the
> >filesystem is getting full and it needs to free some reserved space
> >by flushing cached data which is using reserved extents. Reserved
> >extents do not yet have an on disk address and they include a
> >reservation for the worst case metadata usage. Flushing them will
> >get you room back.
> >
> >As you can see, it is a pretty deep call stack, most of XFS is going
> >to work just fine with a 4K stack, but there are end cases like
> >this one which will just not fit.
> 
> 
> If this is a known truth with XFS maybe it would be a good idea to have 
> 4K stacks and XFS be an impossible combination using the config tool.


The patch below does:

1. let 4KSTACKS depend on EXPERIMENTAL
Rationale:
4Kb stacks on i386 are the future. But currently this option might still 
cause problems in some areas of the kernel. OTOH, 4Kb stacks isn't a big 
gain for most people.
2.6 is a stable kernel series, and 4KSTACKS=n is the safe choice.
Once all issues with 4KSTACKS=y are resolved this can be reverted.

2. let XFS depend on (4KSTACKS=n || BROKEN)
Rationale:
Mark Loy said:
  Don't use 4K stacks and XFS.
Mark this combination as BROKEN until XFS is fixed.
This might result in XFS support disappearing for some people, but if 
they use EXPERIMENTAL=y they should know what they are doing.

The 4KSTACKS option has to be moved for that it's asked before XFS in 
"make config".

diffstat output:
 arch/i386/Kconfig |   19 ++++++++++---------
 fs/Kconfig        |    1 +
 2 files changed, 11 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,16 @@
 	generate incorrect output with certain kernel constructs when
 	-mregparm=3 is used.
 
+config 4KSTACKS
+	bool "Use 4Kb for kernel stacks instead of 8Kb"
+	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
+	  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

  reply	other threads:[~2004-07-20 19:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-20 11:44 4K stack kernel get Oops in Filesystem stress test Cahya Wirawan
2004-07-20 12:04 ` Steve Lord
2004-07-20 14:39   ` Jeffrey E. Hundstad
2004-07-20 19:50     ` Adrian Bunk [this message]
2004-07-20 20:42       ` [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL and XFS on 4KSTACKS=n Chris Wedgwood
2004-07-20 20:50         ` Adrian Bunk
2004-07-20 20:58           ` Chris Wedgwood
2004-07-29  6:09       ` Nathan Scott
2004-07-29 11:42         ` Adrian Bunk
2004-07-29 11:46           ` Arjan van de Ven
2004-07-29 21:11             ` Adrian Bunk
2004-07-29 21:44               ` Chris Wedgwood
2004-07-29 22:30           ` [xfs-masters] " Nathan Scott
2004-08-01 19:02             ` [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL Adrian Bunk
2004-07-29 15:42         ` [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL and XFS on 4KSTACKS=n Mika Bostrom
2004-07-29 16:09           ` Zwane Mwaikambo
2004-07-29 16:36             ` [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL and XFS on 4KSTACKS Mika Bostrom
2004-07-22  7:27     ` 4K stack kernel get Oops in Filesystem stress test Amon Ott
2004-07-29  2:14       ` Nathan Scott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040720195012.GN14733@fs.tum.de \
    --to=bunk@fs.tum.de \
    --cc=akpm@osdl.org \
    --cc=cwirawan@email.archlab.tuwien.ac.at \
    --cc=jeffrey.hundstad@mnsu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=lord@xfs.org \
    --cc=nathans@sgi.com \
    --cc=torvalds@osdl.org \
    --cc=xfs-masters@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.