[-mm patch] i386: enable 4k stacks by default

[-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

This patch enables 4k stacks by default.

4k stacks have become a well-tested feature used fore a long time in
Fedora and even in RHEL 4.

There are no known problems in in-kernel code with 4k stacks still
present after Neil's patch that went into -mm nearly two months ago.

Defaulting to 4k stacks in -mm kernel will give some more testing
coverage and should show whether there are really no problems left.

Keeping the option for now should make the people happy who want to use
the experimental -mm kernel but don't trust the well-tested 4k stacks.

Additionally, make it more obvious that available stack space is not 
being halved.


Signed-off-by: Grant Coady <gcoady@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 Kconfig.debug |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.15a/arch/i386/Kconfig.debug	2005-10-28 10:02:08.000000000 +1000
+++ linux-2.6.15b/arch/i386/Kconfig.debug	2006-01-05 09:39:22.000000000 +1100
@@ -53,14 +53,15 @@
 	  of memory corruptions.
 
 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
+	bool "Use 4Kb + 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
+	default y
 	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.
+	  will also use separate 4Kb IRQ stacks to compensate for the 
+	  reduced stackspace.
 
 config X86_FIND_SMP_CONFIG
 	bool

[-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

4k stacks have become a well-tested feature used fore a long time in
Fedora and even in RHEL 4.

Defaulting to 4k stacks in -mm kernel will give some more testing
coverage and should show whether there are problems left.

Keeping the option for now should make the people happy who want to use
the experimental -mm kernel but don't trust the well-tested 4k stacks.

Additionally, make it more obvious that available stack space is not 
being halved.

Signed-off-by: Grant Coady <gcoady@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This is the original patch that does not the opposite of what it should do.

This patch has been sent on:
- 14 Jan 2006
- 5 Jan 2006

 Kconfig.debug |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.15a/arch/i386/Kconfig.debug	2005-10-28 10:02:08.000000000 +1000
+++ linux-2.6.15b/arch/i386/Kconfig.debug	2006-01-05 09:39:22.000000000 +1100
@@ -53,14 +53,15 @@
 	  of memory corruptions.
 
 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
+	bool "Use 4Kb + 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
+	default y
 	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.
+	  will also use separate 4Kb IRQ stacks to compensate for the 
+	  reduced stackspace.
 
 config X86_FIND_SMP_CONFIG
 	bool

Re: [-mm patch] i386: enable 4k stacks by default

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> 4k stacks have become a well-tested feature used fore a long time in
> Fedora and even in RHEL 4.

So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
DM mirror?

Our 32-bit Fedora Core 5 dual Opteron server at work crashed once a week
while running rdiff-backup off a snapshot.  Installing a 64-bit kernel
stopped the crashes, and I believe the 64-bit still uses the bigger
stacks.
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [-mm patch] i386: enable 4k stacks by default

[David Chinner]

On Sat, Apr 28, 2007 at 03:18:38PM -0600, Zan Lynx wrote:
> On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > 4k stacks have become a well-tested feature used fore a long time in
> > Fedora and even in RHEL 4.
> 
> So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> DM mirror?

I doubt it.  Every time this comes up the problem of stacked I/O
configuration being able to reliably blow the 4k stack limit comes
up. Usually it's XFS that is blamed, but it seems ext3 and reiser
can both suffer from the same problem.  And now we can add things
like unionfs/ecryptfs into the stack as well....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [-mm patch] i386: enable 4k stacks by default

[Alan Cox]

> I doubt it.  Every time this comes up the problem of stacked I/O
> configuration being able to reliably blow the 4k stack limit comes
> up. Usually it's XFS that is blamed, but it seems ext3 and reiser
> can both suffer from the same problem.  And now we can add things
> like unionfs/ecryptfs into the stack as well....

The 8K stack selection does not change this, it just means that if there
is a problem it'll randomly blow up when the heavy IRQ user and the heavy
non-IRQ user occur at the right moments. If this still occurs for some
combinations then the fix would be 8K + 4K IRQ stack, not just to use 8K
stack

Alan

Re: [-mm patch] i386: enable 4k stacks by default

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> If this still occurs for some
> combinations then the fix would be 8K + 4K IRQ stack, not just to use 8K
> stack

Yes i've been thinking for some time doing that would be a good idea.

-Andi

Re: [-mm patch] i386: enable 4k stacks by default

[Christoph Hellwig]

On Mon, Apr 30, 2007 at 12:26:42PM +0200, Andi Kleen wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > If this still occurs for some
> > combinations then the fix would be 8K + 4K IRQ stack, not just to use 8K
> > stack
> 
> Yes i've been thinking for some time doing that would be a good idea.

Yes, the non-irqstack case should definitively go away.  And 8k
kernel stacks isn't that little given how much most 64bit architectures
have.

Re: [-mm patch] i386: enable 4k stacks by default

[Andi Kleen]

Christoph Hellwig <hch@infradead.org> writes:

> On Mon, Apr 30, 2007 at 12:26:42PM +0200, Andi Kleen wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > 
> > > If this still occurs for some
> > > combinations then the fix would be 8K + 4K IRQ stack, not just to use 8K
> > > stack
> > 
> > Yes i've been thinking for some time doing that would be a good idea.
> 
> Yes, the non-irqstack case should definitively go away.  And 8k
> kernel stacks isn't that little given how much most 64bit architectures
> have.

Actually looking at the code it would need some fixes first:

/*
 * These should really be __section__(".bss.page_aligned") as well, but
 * gcc's 3.0 and earlier don't handle that correctly.
 */
static char softirq_stack[NR_CPUS * THREAD_SIZE]
                __attribute__((__aligned__(THREAD_SIZE)));

static char hardirq_stack[NR_CPUS * THREAD_SIZE]
                __attribute__((__aligned__(THREAD_SIZE)));


With 8K stacks and NR_CPUS==128 that would be 2MB statically reserved. Yuck.
Really needs to be dynamically allocated. I'll take a look once the .22 
big merge is done.

-Andi

Re: [-mm patch] i386: enable 4k stacks by default

[William Lee Irwin III]

On Mon, Apr 30, 2007 at 02:13:16PM +0200, Andi Kleen wrote:
> Actually looking at the code it would need some fixes first:
> /*
>  * These should really be __section__(".bss.page_aligned") as well, but
>  * gcc's 3.0 and earlier don't handle that correctly.
>  */
> static char softirq_stack[NR_CPUS * THREAD_SIZE]
>                 __attribute__((__aligned__(THREAD_SIZE)));
> 
> static char hardirq_stack[NR_CPUS * THREAD_SIZE]
>                 __attribute__((__aligned__(THREAD_SIZE)));
> 
> With 8K stacks and NR_CPUS==128 that would be 2MB statically reserved. Yuck.
> Really needs to be dynamically allocated. I'll take a look once the .22 
> big merge is done.

Here's what I did for i386 for someone concerned about blowing the stack.


-- wli

Re: [-mm patch] i386: enable 4k stacks by default

[Jan Engelhardt]

On Apr 30 2007 10:38, William Lee Irwin III wrote:
>> static char softirq_stack[NR_CPUS * THREAD_SIZE]
>>                 __attribute__((__aligned__(THREAD_SIZE)));
>> 
>> static char hardirq_stack[NR_CPUS * THREAD_SIZE]
>>                 __attribute__((__aligned__(THREAD_SIZE)));
>> 
>> With 8K stacks and NR_CPUS==128 that would be 2MB statically reserved. Yuck.
>> Really needs to be dynamically allocated. I'll take a look once the .22 
>> big merge is done.
>
>Here's what I did for i386 for someone concerned about blowing the stack.

If we really need it, then maybe a variable like CONFIG_LOG_BUF_SHIFT
could be hacked up, resulting in CONFIG_THREAD_SIZE_SHIFT, defaulting to 3
(=8KB).


Jan
-- 

Re: [-mm patch] i386: enable 4k stacks by default

[William Lee Irwin III]

On Apr 30 2007 10:38, William Lee Irwin III wrote:
>> Here's what I did for i386 for someone concerned about blowing the stack.

On Mon, Apr 30, 2007 at 08:22:43PM +0200, Jan Engelhardt wrote:
> If we really need it, then maybe a variable like CONFIG_LOG_BUF_SHIFT
> could be hacked up, resulting in CONFIG_THREAD_SIZE_SHIFT, defaulting to 3
> (=8KB).

I wouldn't bother with that. This is all just a sample of apparently
working code that bootmem allocates IRQ stacks.

It's a set of debug patches so there's no intention of any of this
being merged as-posted.


-- wli

Re: [-mm patch] i386: enable 4k stacks by default

[Andi Kleen]

On Mon, Apr 30, 2007 at 10:38:19AM -0700, William Lee Irwin III wrote:
> On Mon, Apr 30, 2007 at 02:13:16PM +0200, Andi Kleen wrote:
> > Actually looking at the code it would need some fixes first:
> > /*
> >  * These should really be __section__(".bss.page_aligned") as well, but
> >  * gcc's 3.0 and earlier don't handle that correctly.
> >  */
> > static char softirq_stack[NR_CPUS * THREAD_SIZE]
> >                 __attribute__((__aligned__(THREAD_SIZE)));
> > 
> > static char hardirq_stack[NR_CPUS * THREAD_SIZE]
> >                 __attribute__((__aligned__(THREAD_SIZE)));
> > 
> > With 8K stacks and NR_CPUS==128 that would be 2MB statically reserved. Yuck.
> > Really needs to be dynamically allocated. I'll take a look once the .22 
> > big merge is done.
> 
> Here's what I did for i386 for someone concerned about blowing the stack.

Looks all good, except for the larger than 8k stack options.
I'll merge it up once the big merge is out of the way.

-Andi

Re: [-mm patch] i386: enable 4k stacks by default

[Neil Brown]

On Saturday April 28, zlynx@acm.org wrote:
> On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > 4k stacks have become a well-tested feature used fore a long time in
> > Fedora and even in RHEL 4.
> 
> So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> DM mirror?

Well -mm has a patch which makes stacked block devices much less of an
issue, but this hasn't made it -linus yet - I think the dm developer
isn't happy that dm works properly with it.

> 
> Our 32-bit Fedora Core 5 dual Opteron server at work crashed once a week
> while running rdiff-backup off a snapshot.  Installing a 64-bit kernel
> stopped the crashes, and I believe the 64-bit still uses the bigger
> stacks.

I wonder if FC-4 has the generic_make_request patch as well as 4K
stacks.  If does, then there is obviously something else to be fixed.
If it doesn't, then maybe that is all that is needed.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/md-dm-reduce-stack-usage-with-stacked-block-devices.patch

NeilBrown

Re: [-mm patch] i386: enable 4k stacks by default

[Christoph Hellwig]

On Mon, Apr 30, 2007 at 06:55:52PM +1000, Neil Brown wrote:
> On Saturday April 28, zlynx@acm.org wrote:
> > On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > > 4k stacks have become a well-tested feature used fore a long time in
> > > Fedora and even in RHEL 4.
> > 
> > So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> > DM mirror?
> 
> Well -mm has a patch which makes stacked block devices much less of an
> issue, but this hasn't made it -linus yet - I think the dm developer
> isn't happy that dm works properly with it.

I get a little tired about this objection.  If the particular dm code
was racy before and this can in theory make it worse it's their problem,
and putting in perfectly fine code will give them an incentive to
fix their year old race.

Re: [-mm patch] i386: enable 4k stacks by default

[Jens Axboe]

On Mon, Apr 30 2007, Christoph Hellwig wrote:
> On Mon, Apr 30, 2007 at 06:55:52PM +1000, Neil Brown wrote:
> > On Saturday April 28, zlynx@acm.org wrote:
> > > On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > > > 4k stacks have become a well-tested feature used fore a long time in
> > > > Fedora and even in RHEL 4.
> > > 
> > > So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> > > DM mirror?
> > 
> > Well -mm has a patch which makes stacked block devices much less of an
> > issue, but this hasn't made it -linus yet - I think the dm developer
> > isn't happy that dm works properly with it.
> 
> I get a little tired about this objection.  If the particular dm code
> was racy before and this can in theory make it worse it's their problem,
> and putting in perfectly fine code will give them an incentive to
> fix their year old race.

Agree, Neil would you mind if I merged the patch?

-- 
Jens Axboe

Re: [-mm patch] i386: enable 4k stacks by default

[Neil Brown]

On Monday April 30, jens.axboe@oracle.com wrote:
> On Mon, Apr 30 2007, Christoph Hellwig wrote:
> > On Mon, Apr 30, 2007 at 06:55:52PM +1000, Neil Brown wrote:
> > > On Saturday April 28, zlynx@acm.org wrote:
> > > > On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > > > > 4k stacks have become a well-tested feature used fore a long time in
> > > > > Fedora and even in RHEL 4.
> > > > 
> > > > So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> > > > DM mirror?
> > > 
> > > Well -mm has a patch which makes stacked block devices much less of an
> > > issue, but this hasn't made it -linus yet - I think the dm developer
> > > isn't happy that dm works properly with it.
> > 
> > I get a little tired about this objection.  If the particular dm code
> > was racy before and this can in theory make it worse it's their problem,
> > and putting in perfectly fine code will give them an incentive to
> > fix their year old race.
> 
> Agree, Neil would you mind if I merged the patch?

I am perfectly happy with this patch being merged - yes.

NeilBrown

Re: [-mm patch] i386: enable 4k stacks by default

[Jens Axboe]

On Tue, May 01 2007, Neil Brown wrote:
> On Monday April 30, jens.axboe@oracle.com wrote:
> > On Mon, Apr 30 2007, Christoph Hellwig wrote:
> > > On Mon, Apr 30, 2007 at 06:55:52PM +1000, Neil Brown wrote:
> > > > On Saturday April 28, zlynx@acm.org wrote:
> > > > > On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > > > > > 4k stacks have become a well-tested feature used fore a long time in
> > > > > > Fedora and even in RHEL 4.
> > > > > 
> > > > > So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> > > > > DM mirror?
> > > > 
> > > > Well -mm has a patch which makes stacked block devices much less of an
> > > > issue, but this hasn't made it -linus yet - I think the dm developer
> > > > isn't happy that dm works properly with it.
> > > 
> > > I get a little tired about this objection.  If the particular dm code
> > > was racy before and this can in theory make it worse it's their problem,
> > > and putting in perfectly fine code will give them an incentive to
> > > fix their year old race.
> > 
> > Agree, Neil would you mind if I merged the patch?
> 
> I am perfectly happy with this patch being merged - yes.

Ok, queued for inclusion.

-- 
Jens Axboe

[-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

This patch enables 4k stacks by default.

4k stacks have become a well-tested feature used fore a long time in
Fedora and even in RHEL 4.

There are no known problems in in-kernel code with 4k stacks still
present after Neil's patch that went into -mm nearly two months ago.

Defaulting to 4k stacks in -mm kernel will give some more testing
coverage and should show whether there are really no problems left.

Keeping the option for now should make the people happy who want to use
the experimental -mm kernel but don't trust the well-tested 4k stacks.

Additionally, make it more obvious that available stack space is not 
being halved.


Signed-off-by: Grant Coady <gcoady@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 5 Jan 2006

 Kconfig.debug |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.15a/arch/i386/Kconfig.debug	2005-10-28 10:02:08.000000000 +1000
+++ linux-2.6.15b/arch/i386/Kconfig.debug	2006-01-05 09:39:22.000000000 +1100
@@ -53,14 +53,15 @@
 	  of memory corruptions.
 
 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
+	bool "Use 4Kb + 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
+	default y
 	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.
+	  will also use separate 4Kb IRQ stacks to compensate for the 
+	  reduced stackspace.
 
 config X86_FIND_SMP_CONFIG
 	bool

[-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

This patch enables 4k stacks by default.

4k stacks have become a well-tested feature used fore a long time in 
Fedora and even in RHEL 4.

There are no known problems in in-kernel code with 4k stacks still 
present after Neil's patch that went into -mm nearly two months ago.

Defaulting to 4k stacks in -mm kernel will give some more testing 
coverage and should show whether there are really no problems left.

Keeping the option for now should make the people happy who want to use 
the experimental -mm kernel but don't trust the well-tested 4k stacks.


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

--- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old	2006-01-04 11:43:55.000000000 +0100
+++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug	2006-01-04 11:44:14.000000000 +0100
@@ -53,8 +53,8 @@
 	  If in doubt, say "N".
 
 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
+	bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
+	default y
 	help
 	  If you say Y here the kernel will use a 4Kb stacksize for the
 	  kernel stack attached to each process/thread. This facilitates

Re: [-mm patch] i386: enable 4k stacks by default

[Jesper Juhl]

On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> This patch enables 4k stacks by default.
>
> 4k stacks have become a well-tested feature used fore a long time in
> Fedora and even in RHEL 4.
>
> There are no known problems in in-kernel code with 4k stacks still
> present after Neil's patch that went into -mm nearly two months ago.
>
> Defaulting to 4k stacks in -mm kernel will give some more testing
> coverage and should show whether there are really no problems left.
>
> Keeping the option for now should make the people happy who want to use
> the experimental -mm kernel but don't trust the well-tested 4k stacks.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old       2006-01-04 11:43:55.000000000 +0100
> +++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug   2006-01-04 11:44:14.000000000 +0100
> @@ -53,8 +53,8 @@
>           If in doubt, say "N".
>
>  config 4KSTACKS
> -       bool "Use 4Kb for kernel stacks instead of 8Kb"
> -       depends on DEBUG_KERNEL
> +       bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL

Why "if DEBUG_KERNEL" ?


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

On Wed, Jan 04, 2006 at 05:39:14PM +0100, Jesper Juhl wrote:
> On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > This patch enables 4k stacks by default.
> >
> > 4k stacks have become a well-tested feature used fore a long time in
> > Fedora and even in RHEL 4.
> >
> > There are no known problems in in-kernel code with 4k stacks still
> > present after Neil's patch that went into -mm nearly two months ago.
> >
> > Defaulting to 4k stacks in -mm kernel will give some more testing
> > coverage and should show whether there are really no problems left.
> >
> > Keeping the option for now should make the people happy who want to use
> > the experimental -mm kernel but don't trust the well-tested 4k stacks.
> >
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> > --- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old       2006-01-04 11:43:55.000000000 +0100
> > +++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug   2006-01-04 11:44:14.000000000 +0100
> > @@ -53,8 +53,8 @@
> >           If in doubt, say "N".
> >
> >  config 4KSTACKS
> > -       bool "Use 4Kb for kernel stacks instead of 8Kb"
> > -       depends on DEBUG_KERNEL
> > +       bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
> 
> Why "if DEBUG_KERNEL" ?

This is simply the same as before with the defaults inverted.

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: [-mm patch] i386: enable 4k stacks by default

[Jesper Juhl]

On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Wed, Jan 04, 2006 at 05:39:14PM +0100, Jesper Juhl wrote:
> > On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > This patch enables 4k stacks by default.
> > >
> > > 4k stacks have become a well-tested feature used fore a long time in
> > > Fedora and even in RHEL 4.
> > >
> > > There are no known problems in in-kernel code with 4k stacks still
> > > present after Neil's patch that went into -mm nearly two months ago.
> > >
> > > Defaulting to 4k stacks in -mm kernel will give some more testing
> > > coverage and should show whether there are really no problems left.
> > >
> > > Keeping the option for now should make the people happy who want to use
> > > the experimental -mm kernel but don't trust the well-tested 4k stacks.
> > >
> > >
> > > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > >
> > > --- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old       2006-01-04 11:43:55.000000000 +0100
> > > +++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug   2006-01-04 11:44:14.000000000 +0100
> > > @@ -53,8 +53,8 @@
> > >           If in doubt, say "N".
> > >
> > >  config 4KSTACKS
> > > -       bool "Use 4Kb for kernel stacks instead of 8Kb"
> > > -       depends on DEBUG_KERNEL
> > > +       bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
> >
> > Why "if DEBUG_KERNEL" ?
>
> This is simply the same as before with the defaults inverted.
>
I just thought that you wanted to get as much testing in -mm as
possible while still leaving the old stacksize option for those who
don't yet trust 4K stacks.
To get maximum testing making 4KSTACKS default Y and removing the "if
DEBUG_KERNEL" conditional just seems to me to be the obvious choice...

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

On Wed, Jan 04, 2006 at 05:49:25PM +0100, Jesper Juhl wrote:
> On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Wed, Jan 04, 2006 at 05:39:14PM +0100, Jesper Juhl wrote:
> > > On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > > This patch enables 4k stacks by default.
> > > >
> > > > 4k stacks have become a well-tested feature used fore a long time in
> > > > Fedora and even in RHEL 4.
> > > >
> > > > There are no known problems in in-kernel code with 4k stacks still
> > > > present after Neil's patch that went into -mm nearly two months ago.
> > > >
> > > > Defaulting to 4k stacks in -mm kernel will give some more testing
> > > > coverage and should show whether there are really no problems left.
> > > >
> > > > Keeping the option for now should make the people happy who want to use
> > > > the experimental -mm kernel but don't trust the well-tested 4k stacks.
> > > >
> > > >
> > > > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > > >
> > > > --- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old       2006-01-04 11:43:55.000000000 +0100
> > > > +++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug   2006-01-04 11:44:14.000000000 +0100
> > > > @@ -53,8 +53,8 @@
> > > >           If in doubt, say "N".
> > > >
> > > >  config 4KSTACKS
> > > > -       bool "Use 4Kb for kernel stacks instead of 8Kb"
> > > > -       depends on DEBUG_KERNEL
> > > > +       bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
> > >
> > > Why "if DEBUG_KERNEL" ?
> >
> > This is simply the same as before with the defaults inverted.
> >
> I just thought that you wanted to get as much testing in -mm as
> possible while still leaving the old stacksize option for those who
> don't yet trust 4K stacks.

That is what my patch does.

> To get maximum testing making 4KSTACKS default Y and removing the "if
> DEBUG_KERNEL" conditional just seems to me to be the obvious choice...

With my version, we are getting the bigger testing coverage - and 
getting a big testing coverage in -mm is what we need if we want to know 
whether we have really already fixed all stack problems or whether 
there are any left.

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: [-mm patch] i386: enable 4k stacks by default

[Jesper Juhl]

On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Wed, Jan 04, 2006 at 05:49:25PM +0100, Jesper Juhl wrote:
> > To get maximum testing making 4KSTACKS default Y and removing the "if
> > DEBUG_KERNEL" conditional just seems to me to be the obvious choice...
>
> With my version, we are getting the bigger testing coverage - and
> getting a big testing coverage in -mm is what we need if we want to know
> whether we have really already fixed all stack problems or whether
> there are any left.
>
Ok, I guess I didn't make myself as clear as I thought.
What I meant was that if 4K stacks are always enabled by default, then
you'll get more testing than if only people who enable DEBUG_KERNEL
are able to turn it on.

So I guess what I'm really aiming at is to either move the option up a
level - that is, remove its dependency on CONFIG_DEBUG_KERNEL, or turn
the option on its head and make it an option to enable 8K stacks
instead and make that option then default to N (I like the first
aproach better though).

Something like this :

--- linux-2.6.15-orig/arch/i386/Kconfig.debug   2006-01-03
04:21:10.000000000 +0100
+++ linux-2.6.15/arch/i386/Kconfig.debug        2006-01-04
19:08:43.000000000 +0100
@@ -44,7 +44,7 @@

 config 4KSTACKS
        bool "Use 4Kb for kernel stacks instead of 8Kb"
-       depends on DEBUG_KERNEL
+       default y
        help
          If you say Y here the kernel will use a 4Kb stacksize for the
          kernel stack attached to each process/thread. This facilitates

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

On Wed, Jan 04, 2006 at 06:10:45PM +0100, Jesper Juhl wrote:
> On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Wed, Jan 04, 2006 at 05:49:25PM +0100, Jesper Juhl wrote:
> > > To get maximum testing making 4KSTACKS default Y and removing the "if
> > > DEBUG_KERNEL" conditional just seems to me to be the obvious choice...
> >
> > With my version, we are getting the bigger testing coverage - and
> > getting a big testing coverage in -mm is what we need if we want to know
> > whether we have really already fixed all stack problems or whether
> > there are any left.
> >
> Ok, I guess I didn't make myself as clear as I thought.
> What I meant was that if 4K stacks are always enabled by default, then
> you'll get more testing than if only people who enable DEBUG_KERNEL
> are able to turn it on.
>...

This is not what my patch does.

Please apply my patch, use DEBUG_KERNEL=n and you'll understand it.

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: [-mm patch] i386: enable 4k stacks by default

[Jesper Juhl]

On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Wed, Jan 04, 2006 at 06:10:45PM +0100, Jesper Juhl wrote:
> > On 1/4/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Wed, Jan 04, 2006 at 05:49:25PM +0100, Jesper Juhl wrote:
> > > > To get maximum testing making 4KSTACKS default Y and removing the "if
> > > > DEBUG_KERNEL" conditional just seems to me to be the obvious choice...
> > >
> > > With my version, we are getting the bigger testing coverage - and
> > > getting a big testing coverage in -mm is what we need if we want to know
> > > whether we have really already fixed all stack problems or whether
> > > there are any left.
> > >
> > Ok, I guess I didn't make myself as clear as I thought.
> > What I meant was that if 4K stacks are always enabled by default, then
> > you'll get more testing than if only people who enable DEBUG_KERNEL
> > are able to turn it on.
> >...
>
> This is not what my patch does.
>
> Please apply my patch, use DEBUG_KERNEL=n and you'll understand it.
>
I see now what it is your patch does. I misread it - sorry - should
have just downloaded it and tried it.
It does exactely what I thought it didn't do - I like it :-)


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [-mm patch] i386: enable 4k stacks by default

[Grant Coady]

On Wed, 4 Jan 2006 15:51:38 +0100, Adrian Bunk <bunk@stusta.de> wrote:

>This patch enables 4k stacks by default.
>
>4k stacks have become a well-tested feature used fore a long time in 
>Fedora and even in RHEL 4.
>
>There are no known problems in in-kernel code with 4k stacks still 
>present after Neil's patch that went into -mm nearly two months ago.
>
>Defaulting to 4k stacks in -mm kernel will give some more testing 
>coverage and should show whether there are really no problems left.
>
>Keeping the option for now should make the people happy who want to use 
>the experimental -mm kernel but don't trust the well-tested 4k stacks.
>
>
>Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>--- linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug.old	2006-01-04 11:43:55.000000000 +0100
>+++ linux-2.6.15-rc5-mm3-full/arch/i386/Kconfig.debug	2006-01-04 11:44:14.000000000 +0100
>@@ -53,8 +53,8 @@
> 	  If in doubt, say "N".
> 
> config 4KSTACKS
>-	bool "Use 4Kb for kernel stacks instead of 8Kb"
>-	depends on DEBUG_KERNEL
>+	bool "Use 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
>+	default y
> 	help
> 	  If you say Y here the kernel will use a 4Kb stacksize for the
> 	  kernel stack attached to each process/thread. This facilitates

Perhaps mention 4k + 4k stacks, the separate irq stacks used with 4k option?  

Grant.

Re: [-mm patch] i386: enable 4k stacks by default

[Adrian Bunk]

On Thu, Jan 05, 2006 at 07:53:00AM +1100, Grant Coady wrote:
> On Wed, 4 Jan 2006 15:51:38 +0100, Adrian Bunk <bunk@stusta.de> wrote:
>...
> > 	  If you say Y here the kernel will use a 4Kb stacksize for the
> > 	  kernel stack attached to each process/thread. This facilitates
> 
> Perhaps mention 4k + 4k stacks, the separate irq stacks used with 4k option?  

Feel free to submit a patch.  ;-)

> Grant.

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: [-mm patch] i386: enable 4k stacks by default

[Grant Coady]

On Wed, 4 Jan 2006 22:00:45 +0100, Adrian Bunk <bunk@stusta.de> wrote:

>On Thu, Jan 05, 2006 at 07:53:00AM +1100, Grant Coady wrote:
>> On Wed, 4 Jan 2006 15:51:38 +0100, Adrian Bunk <bunk@stusta.de> wrote:
>>...
>> > 	  If you say Y here the kernel will use a 4Kb stacksize for the
>> > 	  kernel stack attached to each process/thread. This facilitates
>> 
>> Perhaps mention 4k + 4k stacks, the separate irq stacks used with 4k option?  
>
>Feel free to submit a patch.  ;-)

Okay :)


Based on Adrian Bunk's patch, default to 4k +4k stacks and making 
it more obvious that available stack space is not being halved.
Compile tested.

Signed-off-by: Grant Coady <gcoady@gmail.com>

---
 Kconfig.debug |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.15a/arch/i386/Kconfig.debug	2005-10-28 10:02:08.000000000 +1000
+++ linux-2.6.15b/arch/i386/Kconfig.debug	2006-01-05 09:39:22.000000000 +1100
@@ -53,14 +53,15 @@
 	  of memory corruptions.
 
 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
+	bool "Use 4Kb + 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
+	default y
 	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.
+	  will also use separate 4Kb IRQ stacks to compensate for the 
+	  reduced stackspace.
 
 config X86_FIND_SMP_CONFIG
 	bool