Re: [2.6 patch] i386: always use 4k stacks

Re: [2.6 patch] i386: always use 4k stacks

[Robert Hancock]

Jeff V. Merkey wrote:
> Why does the kernel need to be limited to 4K? for kernel preemption?

No, because it makes a whole lot of things simpler and more reliable if 
the kernel stack is only one page.

> 
> Someone needs to fix this. It's busted. It makes porting code between 
> Windows and Linux and other OS's difficult to support.

Ease of porting drivers written for other OSes to Linux is clearly not a 
high priority for the kernel community..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Robert Hancock wrote:

> Jeff V. Merkey wrote:
>
>> Why does the kernel need to be limited to 4K? for kernel preemption?
>
>
> No, because it makes a whole lot of things simpler and more reliable 
> if the kernel stack is only one page.
>
>>
>> Someone needs to fix this. It's busted. It makes porting code between 
>> Windows and Linux and other OS's difficult to support.
>
>
> Ease of porting drivers written for other OSes to Linux is clearly not 
> a high priority for the kernel community..


What?  There's more kernel apps than just ndis network drivers that get 
ported.  ndiswrapper is busted (which is used for a lot of laptops)
without 4K stacks.  My laptop is a Compaq and there isn't a Linux driver 
for the wireless.  I also discovered Fedora Core 4 won't install
on a Compaq Presario with SATA (stacks crashes). 

What are you saying?   People with wireless and laptops who run Linux 
can't because ndiswrapper is busted without 8K stacks?

Should be a configurable option 4-16K -- set at RUN TIME on the COMMAND 
LINE of the BOOT LOADER.   Peopl can set
profile=? why not kernel default stack size.   That way Fedora, ES, AS, 
and Suse can run out of the box on laptops like Windows,
or is M$ going to keep owning the desktop?
 
Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Robert Hancock]

Jeff V. Merkey wrote:
> What?  There's more kernel apps than just ndis network drivers that get 
> ported.  ndiswrapper is busted (which is used for a lot of laptops)
> without 4K stacks.

Which is why ndiswrapper needs to get fixed to work with 4K stacks. 
ndiswrapper is the thing that's doing the wierd stuff, it needs to adapt 
to the kernel, not the other way around. The reasons to use 4K stacks 
are strong enough that they are not made up for by the fact that 
ndiswrapper currently would like to have more stack space.

Windows apparently has 12K of kernel stack for drivers.. in that case 
even 8K of stack in Linux would not necessarily be enough. If 
ndiswrapper wants to run Windows code in the kernel with any amount of 
reliability it should be providing its own stack which is the size that 
the code expects.

> My laptop is a Compaq and there isn't a Linux driver 
> for the wireless.  I also discovered Fedora Core 4 won't install
> on a Compaq Presario with SATA (stacks crashes).

How do you know this is related to the stack? Did you report this as a bug?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Robert Hancock wrote:

> Jeff V. Merkey wrote:
>
>> What?  There's more kernel apps than just ndis network drivers that 
>> get ported.  ndiswrapper is busted (which is used for a lot of laptops)
>> without 4K stacks.
>
>
> Which is why ndiswrapper needs to get fixed to work with 4K stacks. 
> ndiswrapper is the thing that's doing the wierd stuff, it needs to 
> adapt to the kernel, not the other way around. The reasons to use 4K 
> stacks are strong enough that they are not made up for by the fact 
> that ndiswrapper currently would like to have more stack space.

The NDIS drivers require the 8K stack, not ndiswrapper.

>
> Windows apparently has 12K of kernel stack for drivers.. in that case 
> even 8K of stack in Linux would not necessarily be enough. If 
> ndiswrapper wants to run Windows code in the kernel with any amount of 
> reliability it should be providing its own stack which is the size 
> that the code expects.
>
>> My laptop is a Compaq and there isn't a Linux driver for the 
>> wireless.  I also discovered Fedora Core 4 won't install
>> on a Compaq Presario with SATA (stacks crashes).
>
>
> How do you know this is related to the stack? Did you report this as a 
> bug?


Because I use MDB, a kernel debugger I wrote that inserts beneath Linux 
via DRLX or inside of it, and I watched it crash in the Linux SCSI 
code.  There's code in Linux proper that also walks off the end of the 
stack.  No I did not report it.  But now I have.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Bernd Petrovitsch]

On Mon, 2005-11-14 at 22:31 -0600, Robert Hancock wrote:
> Jeff V. Merkey wrote:
> > What?  There's more kernel apps than just ndis network drivers that get 
> > ported.  ndiswrapper is busted (which is used for a lot of laptops)
> > without 4K stacks.
> 
> Which is why ndiswrapper needs to get fixed to work with 4K stacks. 
> ndiswrapper is the thing that's doing the wierd stuff, it needs to adapt 
> to the kernel, not the other way around. The reasons to use 4K stacks 
> are strong enough that they are not made up for by the fact that 
> ndiswrapper currently would like to have more stack space.

There was a discussion weeks (or already months?) ago about this. The
ndiswrapper maintainer had no problem with private stacks for the NDIS
drivers but IIRC there where some issues with callbacks from the NDIS
drivers which led to the conclusion that it's way too much of a hassle
to get it working and stable.
And yes, you need ndiswrapper for almost all of the WLAN drivers since
there is no documentation of them.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> And yes, you need ndiswrapper for almost all of the WLAN drivers since
> there is no documentation of them.

you're wrong.


documentation for broadcom wireless:
http://bcm-specs.sipsolutions.net/
embrionic driver based on this spec:
http://bcm43xx.berlios.de/

driver for atheros wireless is nearly done:
http://www.selenic.com/pipermail/kernel-mentors/2005-August/000351.html


now if people started to help these folks instead of crying for
ndiswrapper binary solutions maybe those drivers will be finished
quicker.

Re: [2.6 patch] i386: always use 4k stacks

[Jeffrey V. Merkey]

Arjan van de Ven wrote:

>>And yes, you need ndiswrapper for almost all of the WLAN drivers since
>>there is no documentation of them.
>>    
>>
>
>you're wrong.
>
>
>documentation for broadcom wireless:
>http://bcm-specs.sipsolutions.net/
>embrionic driver based on this spec:
>http://bcm43xx.berlios.de/
>
>driver for atheros wireless is nearly done:
>http://www.selenic.com/pipermail/kernel-mentors/2005-August/000351.html
>
>
>now if people started to help these folks instead of crying for
>ndiswrapper binary solutions maybe those drivers will be finished
>quicker.
>  
>

No one is crying about ndiswrapper, some folks just want to use Linux on 
their laptops without waiting
two years for all the drivers to port to Linux.  Make the 4K stack 
setting a command line option.   Problem solved.

Jeff

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

Re: [2.6 patch] i386: always use 4k stacks

[Meelis Roos]

JVM> No one is crying about ndiswrapper, some folks just want to use Linux on 
JVM> their laptops without waiting
JVM> two years for all the drivers to port to Linux.  Make the 4K stack 
JVM> setting a command line option.   Problem solved.

Just do a "fgrep -rI CONFIG_4KSTACKS linux" and see that this is just
not a matter of one malloc call but the code differs in many things.
That's what gives 4KSTACKS its strength.

-- 
Meelis Roos

Re: [2.6 patch] i386: always use 4k stacks

[Cal Peake]

On Tue, 15 Nov 2005, Arjan van de Ven wrote:

> documentation for broadcom wireless:
> http://bcm-specs.sipsolutions.net/
> embrionic driver based on this spec:
> http://bcm43xx.berlios.de/

Thanks, someone mentioned this but didn't provide any links...

> now if people started to help these folks instead of crying for
> ndiswrapper binary solutions maybe those drivers will be finished
> quicker.

Indeed, time to dig out my Linksys WPC54G.

-cp

-- 
Phishing, pharming; n.: Ways to obtain phood. -- The Devil's Infosec Dictionary

Re: [2.6 patch] i386: always use 4k stacks

[Bill Davidsen]

Jeff V. Merkey wrote:
> Robert Hancock wrote:
> 
>> Jeff V. Merkey wrote:
>>
>>> Why does the kernel need to be limited to 4K? for kernel preemption?
>>
>>
>>
>> No, because it makes a whole lot of things simpler and more reliable 
>> if the kernel stack is only one page.
>>
>>>
>>> Someone needs to fix this. It's busted. It makes porting code between 
>>> Windows and Linux and other OS's difficult to support.
>>
>>
>>
>> Ease of porting drivers written for other OSes to Linux is clearly not 
>> a high priority for the kernel community..
> 
> 
> 
> What?  There's more kernel apps than just ndis network drivers that get 
> ported.  ndiswrapper is busted (which is used for a lot of laptops)
> without 4K stacks.  My laptop is a Compaq and there isn't a Linux driver 
> for the wireless.  I also discovered Fedora Core 4 won't install
> on a Compaq Presario with SATA (stacks crashes).
> What are you saying?   People with wireless and laptops who run Linux 
> can't because ndiswrapper is busted without 8K stacks?
> 
> Should be a configurable option 4-16K -- set at RUN TIME on the COMMAND 
> LINE of the BOOT LOADER.   Peopl can set
> profile=? why not kernel default stack size.   That way Fedora, ES, AS, 
> and Suse can run out of the box on laptops like Windows,
> or is M$ going to keep owning the desktop?

Having stack size as a compile time value and having it as a runtime 
value are two totally different problems. I just don't see much benefit 
from making changing the size easy, when it is likely to be a VERY 
infrequent need at all.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

Denis Vlasenko <vda@ilport.com.ua> wrote:
> On Wednesday 16 November 2005 00:27, Giridhar Pemmasani wrote:

[because of ndiswrapper, ...]

> Companies got nice excuse for not giving us docs, making those
> months/years even longer.

<snip>

> Ok, how can we make any progress on obtaining docs for TI acx wireless
> chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
> driver already exists (ndiswrapper), go away".

That why are these cards (Netgear WG511) are documented as being supported
in the CONFIG_PRISM54 help text. I asume the list was copied from the same
bad list of supported cards that made me buy one in the first place. If
there was no ndiswrapper support, I'd have been fooled to completely waste
my money, with ndiswrapper I can at least partially use it. I do neither
want to wait some years to use a by-then obsolete card nor can I help
developing a driver beyond doing some testing.

BTW: What about creating a "Native linux support" logo saying "If you find
a slot and plug it in, you can use it with a vanilla kernel on any arch and
get vendor support"? That would help against Netgear's faksimile products of
working models or ATI's claims for having "linux support".
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [2.6 patch] i386: always use 4k stacks

[Bill Davidsen]

Bodo Eggert wrote:

> BTW: What about creating a "Native linux support" logo saying "If you find
> a slot and plug it in, you can use it with a vanilla kernel on any arch and
> get vendor support"? That would help against Netgear's faksimile products of
> working models or ATI's claims for having "linux support".

We can do that. Well, Linus can do that... he holds the trademark, he 
could create a "Linux native driver" emblem. Have to be a tad careful to 
require open source to get it, but I don't know about requiring GPL. In 
the real world a single FOSS driver which could be used for Linux, BSD, 
and Solaris would be easier for a vendor to justify, but it would have 
to be covered by a license which satisfied all applications.

Even if it couldn't be part of a kernel.org source, at least if it were 
available in source it would satisfy better than ndis. Anyone with real 
expertise in what license could apply to all kernels please speak up.

None of this should imply that I have changed my mind about larger stack 
sizes being desirable.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [2.6 patch] i386: always use 4k stacks

[Joshua Hudson]

I feel like putting my two cents in.

Suppose you just made 4K stacks the default. Since users of
ndiswrapper already have to recompile the kernel, making one
configuration change as well can't be that hard, especially since
ndiswrapper checks kernel options when compiling.

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:

> "With some drawbacks" is the point: It has been determined that the
> drawbacks are heavy enough that the 8KiB stack option should go.

Determined by voodoo and wild guessing.

Let's detect the need for 4K stacks: (I hope I found the correct place)

(Maybe the printk should be completely ifdefed, but I'm not sure)


Signed-off-by: Bodo Eggert <7eggert@gmx.de>

--- 2.6.14/kernel/fork.c.ori    2005-12-21 19:06:24.000000000 +0100
+++ 2.6.14/kernel/fork.c        2005-12-21 19:15:23.000000000 +0100
@@ -168,4 +168,9 @@ static struct task_struct *dup_task_stru
        if (!ti) {
                free_task_struct(tsk);
+               printk(KERN_WARNING, "Can't allocate new task structure"
+#ifndef CONFIG_4KSTACKS
+               ". Maybe you could benefit from 4K stacks.\n"
+#endif
+               "\n");
                return NULL;
        }

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [2.6 patch] i386: always use 4k stacks

[Eric Dumazet]

Bodo Eggert a écrit :
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> 
>> "With some drawbacks" is the point: It has been determined that the
>> drawbacks are heavy enough that the 8KiB stack option should go.
> 
> Determined by voodoo and wild guessing.
> 
> Let's detect the need for 4K stacks: (I hope I found the correct place)
> 
> (Maybe the printk should be completely ifdefed, but I'm not sure)
> 
> 
> Signed-off-by: Bodo Eggert <7eggert@gmx.de>
> 
> --- 2.6.14/kernel/fork.c.ori    2005-12-21 19:06:24.000000000 +0100
> +++ 2.6.14/kernel/fork.c        2005-12-21 19:15:23.000000000 +0100
> @@ -168,4 +168,9 @@ static struct task_struct *dup_task_stru
>         if (!ti) {
>                 free_task_struct(tsk);
> +               printk(KERN_WARNING, "Can't allocate new task structure"
> +#ifndef CONFIG_4KSTACKS
> +               ". Maybe you could benefit from 4K stacks.\n"
> +#endif
> +               "\n");
>                 return NULL;
>         }
> 

This patch is not OK but for i386 architecture.

For example, x86_64 cannot use a 4K stack, it needs a 8KB stack (so a order-1 
allocation that may fail)

Eric

Re: [2.6 patch] i386: always use 4k stacks

[Sean]

On Fri, December 23, 2005 5:12 am, Bodo Eggert said:
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
>
>> "With some drawbacks" is the point: It has been determined that the
>> drawbacks are heavy enough that the 8KiB stack option should go.
>
> Determined by voodoo and wild guessing.

Bullshit.  There's no more guessing involved than you thinking 8K stacks
are sufficient.   How do you know that 8K stacks are enough?   If you
don't understand the testing and common sense that has gone into 4K+4K
stacks you should really be putting in a patch for 128K stacks, because
you don't have any proof that 8K stacks are sufficient either (except by
voodoo and wild guessing).   However, if you _do_ understand the testing
and coding methods then you'll see that 4K + 4K stacks are sufficient
(modulo any bugs, which should be fixed).

Sean



>
> Let's detect the need for 4K stacks: (I hope I found the correct place)
>
> (Maybe the printk should be completely ifdefed, but I'm not sure)
>
> Signed-off-by: Bodo Eggert <7eggert@gmx.de>
>
> --- 2.6.14/kernel/fork.c.ori    2005-12-21 19:06:24.000000000 +0100
> +++ 2.6.14/kernel/fork.c        2005-12-21 19:15:23.000000000 +0100
> @@ -168,4 +168,9 @@ static struct task_struct *dup_task_stru
>         if (!ti) {
>                 free_task_struct(tsk);
> +               printk(KERN_WARNING, "Can't allocate new task structure"
> +#ifndef CONFIG_4KSTACKS
> +               ". Maybe you could benefit from 4K stacks.\n"
> +#endif
> +               "\n");
>                 return NULL;
>         }
>

>

Re: [2.6 patch] i386: always use 4k stacks

[Diego Calleja]

El Fri, 23 Dec 2005 11:12:38 +0100,
Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> escribió:

> +               printk(KERN_WARNING, "Can't allocate new task structure"
> +#ifndef CONFIG_4KSTACKS
> +               ". Maybe you could benefit from 4K stacks.\n"
> +#endif
> +               "\

A sarcastic patch, nice. So, lets try to get something useful
from this flamewar...sight.


The 4k patch is being proposed for -mm. Personally I'm _shocked_ that so
many people is trying to avoid _testing_ (-mm is for testing, isn't it)
this feature so hard. Which is surprising, since merging it into -mm
may prove that they're right (people will report bugs caused by 4k
stacks, etc). Maybe 8k groupies are not willing to be proved that
they're right, or they're afraid of being proven that they're
wrong? </sarcasm>

Now, seriously:
I think that most of the 8k groupies don't like 4k not because it
doesn't works in the common case, but because it could cause hangs
that are not easy to reproduce (ie: they are paranoid). The combination
of code paths is too big and complex. I can understand that.

What I don't know is why you think that 8k will be "safe". As far
as I know, there're have been stacks overflows with 8KB stacks in
the past (ie, "hangs that are not easy to reproduce") before the 4k
stack patch was proposed, and the _one_ reason why now it's very
safe to run with 8k stacks is because the 4k stack patch has forced
people to do stack diets, not because 8k is the best option.

We have *NO* *WAY* of proving that it's safe to run either 4k or
8k stacks. Face it. And since such bugs can exist no matter what
stack size you use, the best option (IMO) is to choose the option that
will allow us to hit those bugs _faster_, ie: 4k stacks. From a
engineering point of view, I can't understand why hiding the problem
is better than choosing the path that will allow to hit and fix those
bugs faster. It remembers me of "security through obscurity". What 
we will do when we have too may overflows with 8K? 16K stacks? Oh,
let me guess: "we'll fix it"?. Well, and why can't we fix 4k stacks???

Now, the code is easy to maintain and some people depends on
8k stacks, as akpm pointed out in http://lkml.org/lkml/2005/12/15/336
This patch (http://lkml.org/lkml/2005/12/16/89) stolen from^W^Winspired
by Adrian Bunk defaults to 4k, makes the 8k people happy and it should
make akpm happy too.

Can someone tell me a reason why all this stupid flamewar can't be
solved with that patch?

Re: [2.6 patch] i386: always use 4k stacks

[Pavel Machek]

On Pá 23-12-05 11:12:38, Bodo Eggert wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> 
> > "With some drawbacks" is the point: It has been determined that the
> > drawbacks are heavy enough that the 8KiB stack option should go.
> 
> Determined by voodoo and wild guessing.
> 
> Let's detect the need for 4K stacks: (I hope I found the correct place)
> 
> (Maybe the printk should be completely ifdefed, but I'm not sure)
> 
> 
> Signed-off-by: Bodo Eggert <7eggert@gmx.de>
> 
> --- 2.6.14/kernel/fork.c.ori    2005-12-21 19:06:24.000000000 +0100
> +++ 2.6.14/kernel/fork.c        2005-12-21 19:15:23.000000000 +0100
> @@ -168,4 +168,9 @@ static struct task_struct *dup_task_stru
>         if (!ti) {
>                 free_task_struct(tsk);
> +               printk(KERN_WARNING, "Can't allocate new task structure"
> +#ifndef CONFIG_4KSTACKS
> +               ". Maybe you could benefit from 4K stacks.\n"
> +#endif
> +               "\n");
>                 return NULL;
>         }

Two newlines in case of 4Kstacks...

								Pavel

-- 
Thanks, Sharp!

Re: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:

[...]

> > "With some drawbacks" is the point: It has been determined that the
> > drawbacks are heavy enough that the 8KiB stack option should go.

> Determined by voodoo

Did you see them sticking needles into waxen stacks?

>                      and wild guessing.

More like long experience with the kernel, and sifting many, many bug
reports we've not looked over (and many we probably didn't see).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

> 
> by goig to 4k stacks they are able to be allocated even when memory is 
> badly fragmented, which is not the case while they are 8k.
> 
> David Lang
> 

It's hard to believe all i386 people have a problem with 8K stacks. What you said may be a problem domain bound to a specific workload on i386 with insane amounts of memory and fragmented LOWMEM. - These people can certainly use 4K stacks and no one is preventing that.

But normal people with <=1Gb RAM and using i386 on desktop (I am sure there are many of them) may do OK with 8K stacks if they had a need to do so. (Like running ndiswrapper, or some other thing which requires bigger stacks for that matter.)

Why take away the 8K option which already exists and works for people who need it? Let people choose what suits their needs. Forcing 4K stacks on people and asking them to sacrifice functionality while *gaining nothing* - sure sounds illogical. (You gain from 4K stacks - you have it as default, but technically you gain NOTHING from taking away the 8k option.)

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Sean]

On Tue, December 20, 2005 2:53 pm, Parag Warudkar said:

> Why take away the 8K option which already exists and works for people who
> need it? Let people choose what suits their needs. Forcing 4K stacks on
> people and asking them to sacrifice functionality while *gaining nothing*
> - sure sounds illogical. (You gain from 4K stacks - you have it as
> default, but technically you gain NOTHING from taking away the 8k option.)

Listen, for anyone who "needs" 8K stacks they can maintain the patch
themselves, they don't need it in the mainline kernel.   One of the points
of removing the 8K stack option is to singal to vendors and everyone else
that bugs arising from using 8K stacks and ** ANY ** sloppy code that
_needs_ 8K stacks is no longer appropriate for mainline.  The kernel
doesn't just carry around a bunch of crappy options because someone
somewhere thinks he needs it.

Sean

Re: [2.6 patch] i386: always use 4k stacks

[Jesper Juhl]

On 12/20/05, Parag Warudkar <kernel-stuff@comcast.net> wrote:
> >
> > by goig to 4k stacks they are able to be allocated even when memory is
> > badly fragmented, which is not the case while they are 8k.
> >
> > David Lang
> >
>
> It's hard to believe all i386 people have a problem with 8K stacks. What you said may be a problem domain bound to a specific workload on i386 with insane amounts of memory and fragmented LOWMEM. - These people can certainly use 4K stacks and no one is preventing that.
>

There are more bennefits to 4K stacks than just that.
Arjan posted a nice list a while back :
http://www.ussg.iu.edu/hypermail/linux/kernel/0511.2/0042.html


> But normal people with <=1Gb RAM and using i386 on desktop (I am sure there are many of them) may do OK with 8K stacks if they had a need to do so. (Like running ndiswrapper,

ndiswrapper is not safe even with 8K stacks since Windows allow more
than that, so ndiswrapper can still break with 8K stack - the
ndiswrapper people would be a lot better off by biting the bullet and
implementing their own large stack for the drivers they run and not
depend on the size of the Linux kernels stack.


>or some other thing which requires bigger stacks for that matter.)
>
If that something is in the mainline kernel it should be fixed, if it
is not in mainline then mainline doesn't need to care.


> Why take away the 8K option which already exists and works for people who need it? Let people choose what suits their needs. Forcing 4K stacks on people and asking them to sacrifice functionality while *gaining nothing* - sure sounds illogical. (You gain from 4K stacks - you have it as default, but technically you gain NOTHING from taking away the 8k option.)
>

By taking away the 8K stack option (after a while, we need to make
damn sure all in-kernel code is safe first) I can think of these
bennefits in addition to the technical bennefits of 4K stacks :

 - less code bloat.
 - fewer config options (there are IMHO way too many already).
 - more testing of 4K stacks (since it's the only option everyone will
be using it).
 - pressure on vendors to get their drivers merged into mainline.


--
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: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

Parag Warudkar <kernel-stuff@comcast.net> wrote:
> It's hard to believe all i386 people have a problem with 8K stacks. What
> you said may be a problem domain bound to a specific workload on i386
> with insane amounts of memory and fragmented LOWMEM. - These people can
> certainly use 4K stacks and no one is preventing that.

> But normal people with <=1Gb RAM and using i386 on desktop (I am sure
> there are many of them) may do OK with 8K stacks if they had a need to do
> so. (Like running ndiswrapper, or some other thing which requires bigger
> stacks for that matter.)

But those normal people are most of the users, running non-critical stuff,
and thus are /excellent/ guinea pigs for the "real world users" you
mentioned above ;-)

/me ducks and runs like all LKML is loose
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

> Oh, well, one of the larger drawbacks of 4KiB stacks is the inevitable
> flamewar, each time with /less/ data (this round I've seen none) supporting
> the need for larger stacks, into which all kinds of idiots* are suckered.

At the same time, I haven't seen any data showing what we gain by losing the 8K 
stack option.  Where are the links to posts where people are claiming en masse 
that 8K stacks are causing screwups, halting VM development etc.?

If 8K stacks are something that works, is not default, what do we gain by losing 
it in total? If people need ndiswrapper (I hate it as much as any one else , but come on 
for some people it's the only option) or any other functionality that requires 
bigger stack, let them choose it if they are ready to take whatever risks that come with it. 

To the ndiswrapper users - Do you guys have any real data showing 4K stacks 
result in problems for you? (Since it is dedicated 4K against shared 8K, it 
might as well not cause problems.) If you do then it's clear that 8K shared  
gives more room than 4k dedicated.

Parag

Re: [2.6 patch] i386: always use 4k stacks

[David Lang]

On Tue, 20 Dec 2005, Parag Warudkar wrote:

>> Oh, well, one of the larger drawbacks of 4KiB stacks is the inevitable
>> flamewar, each time with /less/ data (this round I've seen none) supporting
>> the need for larger stacks, into which all kinds of idiots* are suckered.
>
> At the same time, I haven't seen any data showing what we gain by losing the 8K
> stack option.  Where are the links to posts where people are claiming en masse
> that 8K stacks are causing screwups, halting VM development etc.?

by goig to 4k stacks they are able to be allocated even when memory is 
badly fragmented, which is not the case while they are 8k.

David Lang


-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

Parag Warudkar <kernel-stuff@comcast.net> wrote:
> > Oh, well, one of the larger drawbacks of 4KiB stacks is the inevitable
> > flamewar, each time with /less/ data (this round I've seen none) supporting
> > the need for larger stacks, into which all kinds of idiots* are suckered.

> At the same time, I haven't seen any data showing what we gain by losing
> the 8K stack option.

Code simplification (don't need both versions). Simpler kernel configuration. 
Even smaller .config files ;-)

A useful byproduct is more reproducible crashes when the stack overruns (as
8KiB stands, it will crash the same, but only sometimes; probably even
more, as it really is 6KiB for process + IRQ, and with 4KiB they are 4KiB
each). Yes, more crashes is a feature, as it gets fixed faster.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Stefan Rompf]

Andi Kleen wrote:

> Kernel code is getting more complex all the time and running with
> very tight stack is just risky.

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?

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

Stefan

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Sul, 2005-12-18 at 11:49 +0100, Stefan Rompf wrote:
> 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?

Some vendors have shipped distributions configured with 4K stacks for a
long time and monitored bug reports. 

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

Adrian Bunk <bunk@stusta.de> wrote:

> I'm with you that we need a safety net, but I don't see a problem with
> this being between 3kB and 4kB. The goal should be to _never_ use more
> than 3kB stack having a 1kB safety net.
> 
> And in my experience, many stack problems don't come from code getting
> more complex but from people allocating 1kB structs or arrays of
> > 2k chars on the stack. In these cases, the code has to be fixed and
> "make checkstack" makes it easy to find such cases.
> 
> And as a data point, my count of bug reports for problems with in-kernel
> code with 4k stacks after Neil's patch went into -mm is still at 0.

Would you run a desktop with an nfs server on xfs on lvm on dm on SCSI?
Or a productive server on -mm?

IMO it's OK to push 4K stacks in -mm, but one week of no error reports from
a few testers don't make a reliable system.

[...]

> Unfortunately, "is not really something to encourage" doesn'a make
> "happens in real-life applications" impossible...

The same applies to using kernel stack. Therefore I'll want to choose
a bigger stack for my server, which runs less than 100 processes.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 06:57:44AM +0100, Bodo Eggert wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > I'm with you that we need a safety net, but I don't see a problem with
> > this being between 3kB and 4kB. The goal should be to _never_ use more
> > than 3kB stack having a 1kB safety net.
> > 
> > And in my experience, many stack problems don't come from code getting
> > more complex but from people allocating 1kB structs or arrays of
> > > 2k chars on the stack. In these cases, the code has to be fixed and
> > "make checkstack" makes it easy to find such cases.
> > 
> > And as a data point, my count of bug reports for problems with in-kernel
> > code with 4k stacks after Neil's patch went into -mm is still at 0.
> 
> Would you run a desktop with an nfs server on xfs on lvm on dm on SCSI?
> Or a productive server on -mm?
> 
> IMO it's OK to push 4K stacks in -mm, but one week of no error reports from
> a few testers don't make a reliable system.
> [...]

It isn't that 4k stacks were completely untested.

Fedore enables it for a long time.

Even RHEL4 always uses 4k stacks - and RHEL is a distribution many 
people use on their production servers.

> > Unfortunately, "is not really something to encourage" doesn'a make
> > "happens in real-life applications" impossible...
> 
> The same applies to using kernel stack. Therefore I'll want to choose
> a bigger stack for my server, which runs less than 100 processes.

You can always manually adjust THREAD_SIZE if you really want to, but 
there should be no reason to do so.

There are so many possible programming errors in kernel code, and stack 
usage problems are amongst the ones you can find relatively easy...

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] i386: always use 4k stacks

[Michael Poole]

Adrian Bunk writes:

> On Sun, Dec 18, 2005 at 06:57:44AM +0100, Bodo Eggert wrote:
> > 
> > Would you run a desktop with an nfs server on xfs on lvm on dm on SCSI?
> > Or a productive server on -mm?
> > 
> > IMO it's OK to push 4K stacks in -mm, but one week of no error reports from
> > a few testers don't make a reliable system.
> > [...]
> 
> It isn't that 4k stacks were completely untested.
> 
> Fedore enables it for a long time.
> 
> Even RHEL4 always uses 4k stacks - and RHEL is a distribution many 
> people use on their production servers.

As was pointed out previously in this thread, at least one
configuration that is known to have problems with 4k stacks is simply
not supported by RHEL.  How many more are like that?

Michael Poole

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 08:44:56AM -0500, Michael Poole wrote:
> Adrian Bunk writes:
> 
> > On Sun, Dec 18, 2005 at 06:57:44AM +0100, Bodo Eggert wrote:
> > > 
> > > Would you run a desktop with an nfs server on xfs on lvm on dm on SCSI?
> > > Or a productive server on -mm?
> > > 
> > > IMO it's OK to push 4K stacks in -mm, but one week of no error reports from
> > > a few testers don't make a reliable system.
> > > [...]
> > 
> > It isn't that 4k stacks were completely untested.
> > 
> > Fedore enables it for a long time.
> > 
> > Even RHEL4 always uses 4k stacks - and RHEL is a distribution many 
> > people use on their production servers.
> 
> As was pointed out previously in this thread, at least one
> configuration that is known to have problems with 4k stacks is simply
> not supported by RHEL.  How many more are like that?

s/is known/was known/

XFS got fixed and Neil's patch should fix the rest of the problem.

My count of bug reports for problems with 4k stacks after Neil's patch
went into -mm is still at 0.

4k stacks are always used by Fedora.
4k stacks are always used by RHEL4.

Granted, there might be some small areas that are not covered by such
distributions.

You ask "How many more are like that?".
That's exactly the question I want answers for by always enabling it 
in -mm.

-mm is a pretty experimental kernel and everything using it knows about 
this. Many -mm kernels contain more than hundred new patches compared to 
the previous -mm kernel, and some of these patches are of the quality 
"compiles with some specific options set and might not always crash your 
kernel". A patch like always enabling 4k stacks that is essentially 
already used by at least one popular desktop distribution (Fedora) and 
at least one popular server distriution (RHEL4) already had _far_ more 
than the average testing coverage for patches in -mm, so WTF is the 
problem?

> Michael Poole

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] i386: always use 4k stacks

[Alex Davis]

At some time in the not-too-distant past, Giridhar Pemmasani stated:
 
>ndiswrapper is used not just for broadcom. There are plenty of other
>chipsets that don't even have a project started to write open source
>driver.
Amen!!
 
 
>> try to force ndiswrapper junkies over to the driver to get it tested
                            ^^^^^^^
>Shame on you. Your last mail was a promise to be "more reserved". Even
>otherwise, such profanities against a group of people are unwarranted.
Again, AMEN!!!

I code, therefore I am

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

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

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
[Forgot the attachment]

[-- Attachment #2: Example code with temporary struct on stack --]
[-- Type: text/x-c, Size: 151 bytes --]

struct s {
	int a, b, c;
};

void h(struct s *);

int f()
{
	struct s s;
	
	s.a = 3;
        h(&s);
}

int g()
{
        h(&((struct s) {3, 0, 0}));
}

[-- Attachment #3: Type: text/plain, Size: 276 bytes --]

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Neil Brown]

On Friday December 16, vonbrand@inf.utfsm.cl wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> [Forgot the attachment]

Thanks...
Based on that, I tried the following patch, and it didn't change the
amount of space that is reserved on the stack.
  gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)

Further, earlier version of gcc miscompile this construct.
They effectively treat that in-line structure as a 'static', and
seeing notify_change changes .ia_valid, the next time it is called
contents of the structure will be wrong.

NeilBrown


### Diffstat output
 ./fs/nfsd/vfs.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff ./fs/nfsd/vfs.c~current~ ./fs/nfsd/vfs.c
--- ./fs/nfsd/vfs.c~current~	2005-12-19 09:44:20.000000000 +1100
+++ ./fs/nfsd/vfs.c	2005-12-19 09:56:46.000000000 +1100
@@ -923,11 +923,9 @@ nfsd_vfs_write(struct svc_rqst *rqstp, s
 
 	/* clear setuid/setgid flag after write */
 	if (err >= 0 && (inode->i_mode & (S_ISUID | S_ISGID))) {
-		struct iattr	ia;
-		ia.ia_valid = ATTR_KILL_SUID | ATTR_KILL_SGID;
-
 		down(&inode->i_sem);
-		notify_change(dentry, &ia);
+		notify_change(dentry, &((struct iattr)
+		               {.ia_valid = ATTR_KILL_SUID | ATTR_KILL_SGID}));
 		up(&inode->i_sem);
 	}
 

Re: [2.6 patch] i386: always use 4k stacks

[Matt Reuther]

Isn't this patch specifically for the -mm kernel and not mainline? How can 
anyone using a binary driver provide any feedback on an -mm kernel? The 
binary driver taints the kernel, so bug reports are useless.

Furthermore, if you aren't interested in debugging the kernel, why would you 
run the -mm tree or why can't you hack/patch the 8k stacks back in?

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> Enough already!  These concerns have been raised already, and found
> to be insufficient.  There are several points:
> 
> 1)    ndiswrapper is broken already, and works sheerly by luck anyways;
> NT stacks are 12kb, so you're already asking for stack overflows by
> using it.
> 2)    ndiswrapper encourages use of binary drivers instead of the open-
> source ones that need the testers, so you're only hurting yourselves
> in the long run.

ACK. So where is the driver for the Netgear WG511 Softmac card I'm supposed
to test? I bought this card because it was labled as being supported, and it
turned out that it wasn't, and just nobody cared to update the list of
supported cards with the warning about the unsupported variant.

> 3)    All the in-kernel problems have been fixed, and this makes a lot
> of stuff less fragmentation-prone and more reliable.

BTW: Is there any bug report related to 8K stacks?

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [2.6 patch] i386: always use 4k stacks

[Denis Vlasenko]

On Friday 16 December 2005 13:05, Bodo Eggert wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> 
> > Enough already!  These concerns have been raised already, and found
> > to be insufficient.  There are several points:
> > 
> > 1)    ndiswrapper is broken already, and works sheerly by luck anyways;
> > NT stacks are 12kb, so you're already asking for stack overflows by
> > using it.
> > 2)    ndiswrapper encourages use of binary drivers instead of the open-
> > source ones that need the testers, so you're only hurting yourselves
> > in the long run.
> 
> ACK. So where is the driver for the Netgear WG511 Softmac card I'm supposed
> to test? I bought this card because it was labled as being supported, and it
> turned out that it wasn't, and just nobody cared to update the list of
> supported cards with the warning about the unsupported variant.

We do need more people working on wireless front.
OTOH, more people bitching about bad situation on wireless front
doesn't make it any better.
--
vda

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Fri, Dec 16, 2005 at 12:05:18PM +0100, Bodo Eggert wrote:

 > ACK. So where is the driver for the Netgear WG511 Softmac card I'm supposed
 > to test? I bought this card because it was labled as being supported, and it
 > turned out that it wasn't, and just nobody cared to update the list of
 > supported cards with the warning about the unsupported variant.

There are two models of that card with the same name.
The one made in taiwan is a prism54, the one made in china is
something else.  I guess yours is made in China ?

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

On Fri, 16 Dec 2005, Dave Jones wrote:
> On Fri, Dec 16, 2005 at 12:05:18PM +0100, Bodo Eggert wrote:

>  > ACK. So where is the driver for the Netgear WG511 Softmac card I'm supposed
>  > to test? I bought this card because it was labled as being supported, and it
>  > turned out that it wasn't, and just nobody cared to update the list of
>  > supported cards with the warning about the unsupported variant.
> 
> There are two models of that card with the same name.
> The one made in taiwan is a prism54, the one made in china is
> something else.  I guess yours is made in China ?

Yes.
-- 
Saying your system is secure should be considered the same as saying your food
is too hot. Its a temporary condition which is going away even as you speak.
	-- Gandalf Parker

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Fri, 2005-12-16 at 12:05 +0100, Bodo Eggert wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> 
> > Enough already!  These concerns have been raised already, and found
> > to be insufficient.  There are several points:
> > 
> > 1)    ndiswrapper is broken already, and works sheerly by luck anyways;
> > NT stacks are 12kb, so you're already asking for stack overflows by
> > using it.
> > 2)    ndiswrapper encourages use of binary drivers instead of the open-
> > source ones that need the testers, so you're only hurting yourselves
> > in the long run.
> 
> ACK. So where is the driver for the Netgear WG511 Softmac card I'm supposed
> to test? I bought this card because it was labled as being supported, and it
> turned out that it wasn't, and just nobody cared to update the list of
> supported cards with the warning about the unsupported variant.

Um, this is not the developers fault.  Do you think the vendors call the
driver developers to tell them "hey, we just released a new product,
with a name confusingly similar to the one your driver supports, but we
changed the chipset a tiny bit so it won't work with your driver"?
Dream on.

Driver developers are not psychic.  If no USER reported that the new
FooBar1002X is completely different from the FooBar1002, there's no way
for us to know.  Sorry you were unfortunate enough to be the first user
to learn the hard way.  Complain to the vendor not LKML.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Bodo Eggert]

On Fri, 16 Dec 2005, Lee Revell wrote:
> On Fri, 2005-12-16 at 12:05 +0100, Bodo Eggert wrote:

> > So where is the driver for the Netgear WG511 Softmac card I'm supposed
> > to test? I bought this card because it was labled as being supported, and it
> > turned out that it wasn't, and just nobody cared to update the list of
> > supported cards with the warning about the unsupported variant.
> 
> Um, this is not the developers fault.  Do you think the vendors call the
> driver developers to tell them "hey, we just released a new product,
> with a name confusingly similar to the one your driver supports, but we
> changed the chipset a tiny bit so it won't work with your driver"?
> Dream on.

> Driver developers are not psychic.  If no USER reported that the new
> FooBar1002X is completely different from the FooBar1002, there's no way
> for us to know.  Sorry you were unfortunate enough to be the first user
> to learn the hard way.  Complain to the vendor not LKML.

I found the information hidden on the developer's website, IIRC in the 
developer forum and in several threads. I think it's reasonable to beleave 
that the devteam knew.

-- 
Top 100 things you don't want the sysadmin to say:
90. Wow....that seemed _fast_.....

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On Dec 16, 2005, at 03:20, Alex Davis wrote:
> > Maybe nobody YOU know cares. I know a few people who do!!
> 
> I care a lot about having working wireless on my laptop (a  
> PowerBook).  The only way that's going to happen is the bcm43xx  
> project, which I have supported as much as possible from the very  
> beginning.  The reluctance of many people to try out the now WORKING  
> bcm43xx driver or help out with development before it was working has  
> meant that I've had to wait a lot longer than I probably otherwise  
> would have.  ndiswrapper is NOT an answer
 although if you think so,  
> you're welcome to fix it to work with 4k stacks (although it's not  
> like it really ever "worked" with 8k stacks either, NT has 12k).

> So go f*** off and quit trolling the LKML.  If your argument isn't  
> reasonable with valid open-source *technical* basis, I'm sure you  
> have a wide variety of orifices in which you can shove it, because we  
> don't care at all!

So profanity and getting emootional are technical arguments/reasons to
stop stating my opinions??

Hmmm...


> Cheers,
> Kyle Moffett
> 
> --
> Premature optimization is the root of all evil in programming
>    -- C.A.R. Hoare
> 
> 
> 
> 


I code, therefore I am

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 16, 2005, at 03:48, Alex Davis wrote:
> So profanity and getting emotional are technical arguments/reasons  
> to stop stating my opinions??

No, but given that you've blatantly ignored the [1] previous [2]  
several [3] emails [4] containing [5] technical [6] reasons [7] only  
to repeat the same multiply-rejected nontechnical issue for the forty- 
second time, I figured there was no harm in trying something else.   
(BTW: Way to CC a private thread to a public list)

[1]  http://lkml.org/lkml/2005/11/15/228
[2]  http://lkml.org/lkml/2005/11/15/320
[3]  http://lkml.org/lkml/2005/11/15/401
[4]  http://lkml.org/lkml/2005/11/16/43
[5]  http://lkml.org/lkml/2005/11/16/76
[6]  http://lkml.org/lkml/2005/11/16/86
[7]  http://lkml.org/lkml/2005/12/16/24

Cheers,
Kyle Moffett

--
I didn't say it would work as a defense, just that they can spin that  
out for years in court if it came to it.
   -- Rob Landley

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:
   
> (BTW: Way to CC a private thread to a public list)
> 
Ahhh!!!  So when you get upset and show a less pleasant side
of your personality, you don't want others to see?

Classic!!



I code, therefore I am

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 16, 2005, at 09:45, Alex Davis wrote:
> --- Kyle Moffett <mrmacman_g4@mac.com> wrote:
>> (BTW: Way to CC a private thread to a public list)
>>
> Ahhh!!!  So when you get upset and show a less pleasant side of  
> your personality, you don't want others to see?

Personally, I don't care much, however it does reflect rather poorly  
on _your_ netiquette.  Might I remind you that _you_ were the one who  
made the thread private in the first place?  It is generally  
considered poor form to reply privately to someone (indicating that  
you want to continue off-list), and then as soon as they continue  
discussion in off-list fashion, bringing it back on-list whining  
about how they called you names in a private thread.

I've had enough of this nonsense, and I'm just beginning to realize  
that I've been feeding the troll and lowering the S/N ratio.  PLONK!

On a slightly nicer note, I would like to formally apologize to the  
list for the noise that has resulted, and will attempt to be more  
reserved with my replies in the future.

Cheers,
Kyle Moffett

--
Unix was not designed to stop people from doing stupid things,  
because that would also stop them from doing clever things.
   -- Doug Gwyn

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

The problem is that, with laptops, most of the time you DON'T have a choice:
HP and Dell primarily use a Broadcomm integrated wireless card in ther products.
As of yet, there is no open source driver for Broadcomm wireless.

>If 8k stacks get removed, yes. So if you have a chance to choose don't buy a 
>wifi card which doesn't have a native linux driver.
>
>Regards,
>ismail

I code, therefore I am

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Thu, Dec 15, 2005 at 09:20:54PM -0800, Alex Davis wrote:
 > The problem is that, with laptops, most of the time you DON'T have a choice:
 > HP and Dell primarily use a Broadcomm integrated wireless card in ther products.
 > As of yet, there is no open source driver for Broadcomm wireless.

We've already been through all this the previous times this came up.

http://bcm43xx.berlios.de

Whilst it's in early stages, it's making progress.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

--- Dave Jones <davej@redhat.com> wrote:

> On Thu, Dec 15, 2005 at 09:20:54PM -0800, Alex Davis wrote:
>  > The problem is that, with laptops, most of the time you DON'T have a choice:
>  > HP and Dell primarily use a Broadcomm integrated wireless card in ther products.
>  > As of yet, there is no open source driver for Broadcomm wireless.
> 
> We've already been through all this the previous times this came up.
> 
> http://bcm43xx.berlios.de
> 
> Whilst it's in early stages, it's making progress.
> 
> 		Dave
> 
> 
I understand that, and am grateful for the effort, but the point is it's not ready. Are you
expecting people to lose an important feature of their
laptop until you get the driver ready? 


I code, therefore I am

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Pekka Enberg]

Hi Alex,

On 12/16/05, Alex Davis <alex14641@yahoo.com> wrote:
> I understand that, and am grateful for the effort, but the point is it's not ready. Are you
> expecting people to lose an important feature of their
> laptop until you get the driver ready?

Hey, it's the price you pay for using binary only drivers. Why not
complain to Broadcom instead for not releasing the hardware
documentation? Besides, you can still maintain 8 KB stacks as an
out-of-tree patch or change fix ndiswrapper work with 4 KB ones.

                              Pekka

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 16, 2005, at 01:16, Alex Davis wrote:
> [flamewar]

Enough already!  These concerns have been raised already, and found  
to be insufficient.  There are several points:

1)	ndiswrapper is broken already, and works sheerly by luck anyways;  
NT stacks are 12kb, so you're already asking for stack overflows by  
using it.
2)	ndiswrapper encourages use of binary drivers instead of the open- 
source ones that need the testers, so you're only hurting yourselves  
in the long run.
3)	All the in-kernel problems have been fixed, and this makes a lot  
of stuff less fragmentation-prone and more reliable.

Does anybody have any _in_kernel_ bugreports which are unaddressed,  
or maybe something out-of-kernel that is not handled by the above  
points?

Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory  
subsystems, sorry.  It would be like trying to make a human more  
robust with an unreliable O2 supply. Memory just has to work.
   -- Andi Kleen

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 16, 2005, at 01:16, Alex Davis wrote:
> [flamewar]

Enough already!  These concerns have been raised already, and found  
to be insufficient.  There are several points:

1)	ndiswrapper is broken already, and works sheerly by luck anyways;  
NT stacks are 12kb, so you're already asking for stack overflows by  
using it.
2)	ndiswrapper encourages use of binary drivers instead of the open- 
source ones that need the testers, so you're only hurting yourselves  
in the long run.
3)	All the in-kernel problems have been fixed, and this makes a lot  
of stuff less fragmentation-prone and more reliable.

Does anybody have any _in_kernel_ bugreports which are unaddressed,  
or maybe something out-of-kernel that is not handled by the above  
points?

Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory  
subsystems, sorry.  It would be like trying to make a human more  
robust with an unreliable O2 supply. Memory just has to work.
   -- Andi Kleen

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> I understand that, and am grateful for the effort, but the point is it's not ready. Are you
> expecting people to lose an important feature of their
> laptop until you get the driver ready? 
> 
> 
> I code, therefore I am

if you code.. why don't you go help coding with the people writing the
broadcom drivers? How is this ONLY our problem? Linux is a cooperative
thing: you take but you also give back. If you're a coder, this is the
perfect opportunity to give something back and help the bcm43xx guys
with debugging and coding and testing....

Re: [2.6 patch] i386: always use 4k stacks

[David Weinehall]

On Thu, Dec 15, 2005 at 10:16:05PM -0800, Alex Davis wrote:
> 
> 
> --- Dave Jones <davej@redhat.com> wrote:
> 
> > On Thu, Dec 15, 2005 at 09:20:54PM -0800, Alex Davis wrote:
> >  > The problem is that, with laptops, most of the time you DON'T
> >  > have a choice: HP and Dell primarily use a Broadcomm integrated
> >  > wireless card in ther products.  As of yet, there is no open
> >  > source driver for Broadcomm wireless.
> > 
> > We've already been through all this the previous times this came up.
> > 
> > http://bcm43xx.berlios.de
> > 
> > Whilst it's in early stages, it's making progress.
> > 
> > 		Dave
> > 
> > 
> I understand that, and am grateful for the effort, but the point is
> it's not ready. Are you expecting people to lose an important feature
> of their laptop until you get the driver ready? 

Yeah, it must be oh so important for the laptop owners with that
particular chipset to run the -mm experimental kernels instead of, their
distro kernel or the stable 2.6-kernel series or Linus latest
installment (or even a git-snapshot or checkout...)


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [2.6 patch] i386: always use 4k stacks

[Michael Buesch]

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

On Tuesday 27 December 2005 22:03, David Weinehall wrote:
> On Thu, Dec 15, 2005 at 10:16:05PM -0800, Alex Davis wrote:
> > 
> > 
> > --- Dave Jones <davej@redhat.com> wrote:
> > 
> > > On Thu, Dec 15, 2005 at 09:20:54PM -0800, Alex Davis wrote:
> > >  > The problem is that, with laptops, most of the time you DON'T
> > >  > have a choice: HP and Dell primarily use a Broadcomm integrated
> > >  > wireless card in ther products.  As of yet, there is no open
> > >  > source driver for Broadcomm wireless.
> > > 
> > > We've already been through all this the previous times this came up.
> > > 
> > > http://bcm43xx.berlios.de
> > > 
> > > Whilst it's in early stages, it's making progress.
> > > 
> > > 		Dave
> > > 
> > > 
> > I understand that, and am grateful for the effort, but the point is
> > it's not ready. Are you expecting people to lose an important feature
> > of their laptop until you get the driver ready? 
> 
> Yeah, it must be oh so important for the laptop owners with that
> particular chipset to run the -mm experimental kernels instead of, their
> distro kernel or the stable 2.6-kernel series or Linus latest
> installment (or even a git-snapshot or checkout...)

Well, the devicescape port of the bcm43xx driver works
very relieably on my Apple PowerBook with WPA encryption.
(WEP does also work).
I don't think there are lots of issues left for non-AccessPoint
modes. I simply assume you want to run the card in STA mode,
instead of rendering your expensive notebook into an AP. ;)

It's been a long time, since I plugged my ethernet cable into
the notebook the last time... .

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] i386: always use 4k stacks

[Matt Domsch]

On Thu, Dec 15, 2005 at 09:20:54PM -0800, Alex Davis wrote:
> The problem is that, with laptops, most of the time you DON'T have a choice:
> HP and Dell primarily use a Broadcomm integrated wireless card in ther products.
> As of yet, there is no open source driver for Broadcomm wireless.
> 
> >If 8k stacks get removed, yes. So if you have a chance to choose don't buy a 
> >wifi card which doesn't have a native linux driver.

Dell "Software & Peripherals" sells "customer kits" of the Intel
ipw2915 for $59 US, so even if you bought the "wrong" wireless NIC
when you bought the laptop, this can be remedied.

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved at least
in -mm.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for Linus' 
tree.


Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjan@infradead.org>

---

This patch was already sent on:
- 11 Dec 2005
- 5 Dec 2005
- 30 Nov 2005
- 23 Nov 2005
- 14 Nov 2005

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */

--- linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c.old	2005-12-11 15:10:27.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c	2005-12-11 15:11:29.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -55,10 +53,8 @@
 {	
 	/* high bits used in ret_from_ code */
 	int irq = regs->orig_eax & 0xff;
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -76,8 +72,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -104,7 +98,6 @@
 			: "memory", "cc", "ecx"
 		);
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -114,8 +107,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -200,7 +191,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

Re: [2.6 patch] i386: always use 4k stacks

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> This patch was already sent on:
> - 11 Dec 2005
> - 5 Dec 2005
> - 30 Nov 2005
> - 23 Nov 2005
> - 14 Nov 2005

Sigh.  I saw the volume of email last time and though "gee, glad I wasn't
cc'ed on that lot".

Supporting 8k stacks is a small amount of code and nobody has seen a need
to make changes in there for quite a long time.  So there's little cost to
keeping the existing code.

And the existing code is useful:

a) people can enable it to confirm that their weird crash was due to a
   stack overflow.

b) If I was going to put together a maximally-stable kernel for a
   complex server machine, I'd select 8k stacks.  We're still just too
   squeezy, and we've had too many relatively-recent overflows, and there
   are still some really deep callpaths in there.

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Andrew,

Thanks. I concur.

Jeff

Andrew Morton wrote:

>Adrian Bunk <bunk@stusta.de> wrote:
>  
>
>>This patch was already sent on:
>>- 11 Dec 2005
>>- 5 Dec 2005
>>- 30 Nov 2005
>>- 23 Nov 2005
>>- 14 Nov 2005
>>    
>>
>
>Sigh.  I saw the volume of email last time and though "gee, glad I wasn't
>cc'ed on that lot".
>
>Supporting 8k stacks is a small amount of code and nobody has seen a need
>to make changes in there for quite a long time.  So there's little cost to
>keeping the existing code.
>
>And the existing code is useful:
>
>a) people can enable it to confirm that their weird crash was due to a
>   stack overflow.
>
>b) If I was going to put together a maximally-stable kernel for a
>   complex server machine, I'd select 8k stacks.  We're still just too
>   squeezy, and we've had too many relatively-recent overflows, and there
>   are still some really deep callpaths in there.
>
>-
>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/
>
>  
>

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Thu, Dec 15, 2005 at 02:00:13PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > This patch was already sent on:
> > - 11 Dec 2005
> > - 5 Dec 2005
> > - 30 Nov 2005
> > - 23 Nov 2005
> > - 14 Nov 2005
> 
> Sigh.  I saw the volume of email last time and though "gee, glad I wasn't
> cc'ed on that lot".

If you substract the "this breaks my binary-only M$ Windows driver" 
emails there's not much volume left.

> Supporting 8k stacks is a small amount of code and nobody has seen a need
> to make changes in there for quite a long time.  So there's little cost to
> keeping the existing code.
> 
> And the existing code is useful:
> 
> a) people can enable it to confirm that their weird crash was due to a
>    stack overflow.
> 
> b) If I was going to put together a maximally-stable kernel for a
>    complex server machine, I'd select 8k stacks.  We're still just too
>    squeezy, and we've had too many relatively-recent overflows, and there
>    are still some really deep callpaths in there.

a1) People turn off 4k stacks and never report the problem / noone 
    really debugs and fixes the reported problem.

Me threatening people with enabling 4k stacks for everyone already 
resulted in several fixes.

An how many weird crashes with _different_ causes have you seen?
It could be that there are only _very_ few problems that noone really 
debugs brcause disabling 4k stacks fixes the issue.

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] i386: always use 4k stacks

[Jeff V. Merkey]

Adrian Bunk wrote:

>On Thu, Dec 15, 2005 at 02:00:13PM -0800, Andrew Morton wrote:
>  
>
>>Adrian Bunk <bunk@stusta.de> wrote:
>>    
>>
>>>This patch was already sent on:
>>>- 11 Dec 2005
>>>- 5 Dec 2005
>>>- 30 Nov 2005
>>>- 23 Nov 2005
>>>- 14 Nov 2005
>>>      
>>>
>>Sigh.  I saw the volume of email last time and though "gee, glad I wasn't
>>cc'ed on that lot".
>>    
>>
>
>If you substract the "this breaks my binary-only M$ Windows driver" 
>emails there's not much volume left.
>
>  
>
>>Supporting 8k stacks is a small amount of code and nobody has seen a need
>>to make changes in there for quite a long time.  So there's little cost to
>>keeping the existing code.
>>
>>And the existing code is useful:
>>
>>a) people can enable it to confirm that their weird crash was due to a
>>   stack overflow.
>>
>>b) If I was going to put together a maximally-stable kernel for a
>>   complex server machine, I'd select 8k stacks.  We're still just too
>>   squeezy, and we've had too many relatively-recent overflows, and there
>>   are still some really deep callpaths in there.
>>    
>>
>
>a1) People turn off 4k stacks and never report the problem / noone 
>    really debugs and fixes the reported problem.
>
>Me threatening people with enabling 4k stacks for everyone already 
>resulted in several fixes.
>
>An how many weird crashes with _different_ causes have you seen?
>It could be that there are only _very_ few problems that noone really 
>debugs brcause disabling 4k stacks fixes the issue.
>  
>

When you are on the phone with an irrate customer at 2:00 am in the 
morning, and just turning off your broken 4K stack fix
and getting the customer running matters. 4K stacks are a BAD idea. I 
have even found USER SPACE apps
that crash linux without the 8K option. Andrew has spoken. Suck it up 
and deal with it. It's not a problem limited to Windows
drivers.

Jeff

>cu
>Adrian
>
>  
>

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
> When you are on the phone with an irrate customer at 2:00 am in the 
> morning, and just turning off your broken 4K stack fix
> and getting the customer running matters. 

Bugzilla link please.  Otherwise STFU.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Lee Revell wrote:

>On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
>  
>
>>When you are on the phone with an irrate customer at 2:00 am in the 
>>morning, and just turning off your broken 4K stack fix
>>and getting the customer running matters. 
>>    
>>
>
>Bugzilla link please.  Otherwise STFU.
>  
>

??????

Jeff

>Lee
>
>
>  
>

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Thu, 2005-12-15 at 14:46 -0700, Jeff V. Merkey wrote:
> Lee Revell wrote:
> 
> >On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
> >  
> >
> >>When you are on the phone with an irrate customer at 2:00 am in the 
> >>morning, and just turning off your broken 4K stack fix
> >>and getting the customer running matters. 
> >>    
> >>
> >
> >Bugzilla link please.  Otherwise STFU.
> >  
> >
> 
> ??????
> 
> Jeff

You imply that your customer's problem was due to a kernel bug triggered
by CONFIG_4KSTACKS.  I am asking you to provide a link to the bug report
or get lost.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Lee Revell wrote:

>On Thu, 2005-12-15 at 14:46 -0700, Jeff V. Merkey wrote:
>  
>
>>Lee Revell wrote:
>>
>>    
>>
>>>On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
>>> 
>>>
>>>      
>>>
>>>>When you are on the phone with an irrate customer at 2:00 am in the 
>>>>morning, and just turning off your broken 4K stack fix
>>>>and getting the customer running matters. 
>>>>   
>>>>
>>>>        
>>>>
>>>Bugzilla link please.  Otherwise STFU.
>>> 
>>>
>>>      
>>>
>>??????
>>
>>Jeff
>>    
>>
>
>You imply that your customer's problem was due to a kernel bug triggered
>by CONFIG_4KSTACKS.  I am asking you to provide a link to the bug report
>or get lost.
>
>Lee
>  
>

You hack on this code base (hack is the right word) -- I sell it, 
service and support it with customers in a dozen countries.  I don't report
company level issues in "bugzilla" or anywhere else public unless they 
apply to kernel code.  calls from several of our apps (which use
larger than 4K kernel space on a stack) from user space crash -- so do 
wireless drivers -- and kdb crashes as well with some bugs with 4K stacks
turned on when you are trying to debug something. 

Hope that addresses your concerns "joe job".

Jeff

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

Re: [2.6 patch] i386: always use 4k stacks

[Ismail Donmez]

Cuma 16 Aralık 2005 00:04 tarihinde şunları yazmıştınız:
> Lee Revell wrote:
> >On Thu, 2005-12-15 at 14:46 -0700, Jeff V. Merkey wrote:
> >>Lee Revell wrote:
> >>>On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
> >>>>When you are on the phone with an irrate customer at 2:00 am in the
> >>>>morning, and just turning off your broken 4K stack fix
> >>>>and getting the customer running matters.
> >>>
> >>>Bugzilla link please.  Otherwise STFU.
> >>
> >>??????
> >>
> >>Jeff
> >
> >You imply that your customer's problem was due to a kernel bug triggered
> >by CONFIG_4KSTACKS.  I am asking you to provide a link to the bug report
> >or get lost.
> >
> >Lee
>
> You hack on this code base (hack is the right word) -- I sell it,
> service and support it with customers in a dozen countries.  I don't report
> company level issues in "bugzilla" or anywhere else public unless they
> apply to kernel code.  calls from several of our apps (which use
> larger than 4K kernel space on a stack) from user space crash -- so do
> wireless drivers -- and kdb crashes as well with some bugs with 4K stacks
> turned on when you are trying to debug something.
>
> Hope that addresses your concerns "joe job".

You are supposed to report those bugs in a manner it won't conflict with the 
privacy of your customer(s). Linux distros do this already.

/ismail

Re: [2.6 patch] i386: always use 4k stacks

[Fri, 16 Dec 2005 01:08:02 +0100]

El Thu, 15 Dec 2005 15:04:38 -0700,
"Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> escribió:

> apply to kernel code.  calls from several of our apps (which use
> larger than 4K kernel space on a stack) from user space crash -- so do 
> wireless drivers -- and kdb crashes as well with some bugs with 4K stacks
> turned on when you are trying to debug something. 

If you (or other people) don't report those bugs, nobody else except
you will care about them, I'm afraid.

"My customer says it crashes but I don't want to report it publically".
What kind of excuse is that? O_o

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Fri, 16 Dec 2005 01:08:02 +0100 wrote:

>El Thu, 15 Dec 2005 15:04:38 -0700,
>"Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> escribió:
>
>  
>
>>apply to kernel code.  calls from several of our apps (which use
>>larger than 4K kernel space on a stack) from user space crash -- so do 
>>wireless drivers -- and kdb crashes as well with some bugs with 4K stacks
>>turned on when you are trying to debug something. 
>>    
>>
>
>If you (or other people) don't report those bugs, nobody else except
>you will care about them, I'm afraid.
>
>"My customer says it crashes but I don't want to report it publically".
>What kind of excuse is that? O_o
>-
>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/
>
>  
>
You need to go back and read the whole thread.  These bugs were reported 
by me weeks ago.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Michael Buesch]

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

On Friday 16 December 2005 01:08, you wrote:
> El Thu, 15 Dec 2005 15:04:38 -0700,
> "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> escribió:
> 
> > apply to kernel code.  calls from several of our apps (which use
> > larger than 4K kernel space on a stack) from user space crash -- so do 
> > wireless drivers -- and kdb crashes as well with some bugs with 4K stacks
> > turned on when you are trying to debug something. 
> 
> If you (or other people) don't report those bugs, nobody else except
> you will care about them, I'm afraid.
> 
> "My customer says it crashes but I don't want to report it publically".
> What kind of excuse is that? O_o

Your customer runs an -mm kernel on his production systems?
Smash him.
This is about removing 8k support in the -mm kernel, to
find the remaining bugs (if there are any).

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Iau, 2005-12-15 at 15:04 -0700, Jeff V. Merkey wrote:
> apply to kernel code.  calls from several of our apps (which use
> larger than 4K kernel space on a stack) 

Then you've got bugs anyway. In 8K stack mode that stack is shared with
the IRQ/BH/etc stack so you've only got 4K to play with. Its just more
random whether your box explodes.

Re: [2.6 patch] i386: always use 4k stacks

[linux-os (Dick Johnson)]

On Thu, 15 Dec 2005, Lee Revell wrote:

> On Thu, 2005-12-15 at 14:46 -0700, Jeff V. Merkey wrote:
>> Lee Revell wrote:
>>
>>> On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
>>>
>>>
>>>> When you are on the phone with an irrate customer at 2:00 am in the
>>>> morning, and just turning off your broken 4K stack fix
>>>> and getting the customer running matters.
>>>>
>>>>
>>>
>>> Bugzilla link please.  Otherwise STFU.
>>>
>>>
>>
>> ??????
>>
>> Jeff
>
> You imply that your customer's problem was due to a kernel bug triggered
> by CONFIG_4KSTACKS.  I am asking you to provide a link to the bug report
> or get lost.
>
> Lee

Throughout the past two years of 4k stack-wars, I never heard why
such a small stack was needed (not wanted, needed). It seems that
everybody "knows" that smaller is better and most everybody thinks
that one page in ix86 land is "optimum". However I don't think
anybody ever even tried to analyze what was better from a technical
perspective. Instead it's been analyzed as religious dogma, i.e.,
keep the stack small, it will prevent idiots from doing bad things.

I'm fairly sure that if you started from scratch and decided to
write a new operating system, your choice of a stack-size would
probably be something like 64k. I have no clue why somebody
decided to use a 4k stack and force their choice upon others.
And, yes, I am well aware that each system-call requires a
seperate stack upon entry and it even needs to keep that stack
while sleeping.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: [2.6 patch] i386: always use 4k stacks

[Xavier Bestel]

On Fri, 2005-12-16 at 15:39, linux-os (Dick Johnson) wrote:

> Throughout the past two years of 4k stack-wars, I never heard why
> such a small stack was needed (not wanted, needed).

Because after some prolonged uptime, memory can be heavily fragmented.
In this case an order-0 allocation will always succeed (as long as some
memory is free), whereas an order-1 allocation may easily fail.

	Xav

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Fri, Dec 16, 2005 at 09:39:56AM -0500, linux-os (Dick Johnson) wrote:
> 
> Throughout the past two years of 4k stack-wars, I never heard why
> such a small stack was needed (not wanted, needed). It seems that
> everybody "knows" that smaller is better and most everybody thinks
> that one page in ix86 land is "optimum". However I don't think
> anybody ever even tried to analyze what was better from a technical
> perspective. Instead it's been analyzed as religious dogma, i.e.,
> keep the stack small, it will prevent idiots from doing bad things.
>...

It seems you missed the discussion of this issue last month.

Arjan had a good list of all technical advantages of 4k stacks:
  http://www.ussg.iu.edu/hypermail/linux/kernel/0511.2/0042.html

> Cheers,
> Dick Johnson

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] i386: always use 4k stacks

[Horst von Brand]

linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:

[...]

> Throughout the past two years of 4k stack-wars, I never heard why
> such a small stack was needed (not wanted, needed). It seems that
> everybody "knows" that smaller is better and most everybody thinks
> that one page in ix86 land is "optimum". However I don't think
> anybody ever even tried to analyze what was better from a technical
> perspective. Instead it's been analyzed as religious dogma, i.e.,
> keep the stack small, it will prevent idiots from doing bad things.

OK, so here goes again...

The kernel stack has to be contiguous in /physical/ memory. Keep the stack
/one/ page, that way you can always get a new stack when needed (== each
fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
find (or create) a multi-page free area, and (fragmentation being what it
is, and Linux routinely running for months at a time) you are in a whole
new world of pain.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Oliver Neukum]

Am Freitag, 16. Dezember 2005 19:42 schrieb Horst von Brand:
> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
> 
> [...]
> 
> > Throughout the past two years of 4k stack-wars, I never heard why
> > such a small stack was needed (not wanted, needed). It seems that
> > everybody "knows" that smaller is better and most everybody thinks
> > that one page in ix86 land is "optimum". However I don't think
> > anybody ever even tried to analyze what was better from a technical
> > perspective. Instead it's been analyzed as religious dogma, i.e.,
> > keep the stack small, it will prevent idiots from doing bad things.
> 
> OK, so here goes again...
> 
> The kernel stack has to be contiguous in /physical/ memory. Keep the stack
> /one/ page, that way you can always get a new stack when needed (== each
> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
> find (or create) a multi-page free area, and (fragmentation being what it
> is, and Linux routinely running for months at a time) you are in a whole
> new world of pain.

How about ignoring physical pages and going to virtual, say, 16K pages?
After all, 4K is 15 years old. Disks and RAM have grown enormously.

	Regards
		Oliver

Re: [2.6 patch] i386: always use 4k stacks

[Brian Gerst]

Horst von Brand wrote:
> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
> 
> [...]
> 
> 
>>Throughout the past two years of 4k stack-wars, I never heard why
>>such a small stack was needed (not wanted, needed). It seems that
>>everybody "knows" that smaller is better and most everybody thinks
>>that one page in ix86 land is "optimum". However I don't think
>>anybody ever even tried to analyze what was better from a technical
>>perspective. Instead it's been analyzed as religious dogma, i.e.,
>>keep the stack small, it will prevent idiots from doing bad things.
> 
> 
> OK, so here goes again...
> 
> The kernel stack has to be contiguous in /physical/ memory. Keep the stack
> /one/ page, that way you can always get a new stack when needed (== each
> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
> find (or create) a multi-page free area, and (fragmentation being what it
> is, and Linux routinely running for months at a time) you are in a whole
> new world of pain.

So what about arches where single-page stacks aren't viable (for example 
x86_64)?  Are we just screwed?

--
				Brian Gerst

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> 
> So what about arches where single-page stacks aren't viable (for example 
> x86_64)?  Are we just screwed?


x86 is specially handicapped due to the fact that the stacks need to be
in the lowmem zone. Even if you have 8Gb ram, the lowmem zone is still
800Mb and a bit, and this gets to be under a high pressure, like
hyper-fragmentation. Same for bounce buffers etc etc.

note that the order thing is by far not the only advantage, pure memory
usage alone and cache locality also are wins. The memory usage halves
for kernel stacks after all (which means you can do more threads in
java, or use the memory for disk cache ;)

Re: [2.6 patch] i386: always use 4k stacks

[Oliver Neukum]

Am Freitag, 16. Dezember 2005 20:02 schrieb Arjan van de Ven:
> 
> > 
> > So what about arches where single-page stacks aren't viable (for example 
> > x86_64)?  Are we just screwed?
> 
> 
> x86 is specially handicapped due to the fact that the stacks need to be
> in the lowmem zone. Even if you have 8Gb ram, the lowmem zone is still
> 800Mb and a bit, and this gets to be under a high pressure, like
> hyper-fragmentation. Same for bounce buffers etc etc.
> 
> note that the order thing is by far not the only advantage, pure memory
> usage alone and cache locality also are wins. The memory usage halves
> for kernel stacks after all (which means you can do more threads in
> java, or use the memory for disk cache ;)

1. Cache usage depends on actual stack usage. How much you allocate
doesn't matter
2. You are surely getting a cache effect by using interrupt stacks. Which
is larger?
3. When you use kmalloc instead of the stack you are reducing locality.

	Regards
		Oliver

Re: [2.6 patch] i386: always use 4k stacks

[Steven Rostedt]

On Fri, 2005-12-16 at 15:42 -0300, Horst von Brand wrote:
> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
> 
> [...]
> 
> > Throughout the past two years of 4k stack-wars, I never heard why
> > such a small stack was needed (not wanted, needed). It seems that
> > everybody "knows" that smaller is better and most everybody thinks
> > that one page in ix86 land is "optimum". However I don't think
> > anybody ever even tried to analyze what was better from a technical
> > perspective. Instead it's been analyzed as religious dogma, i.e.,
> > keep the stack small, it will prevent idiots from doing bad things.
> 
> OK, so here goes again...
> 
> The kernel stack has to be contiguous in /physical/ memory. Keep the stack
> /one/ page, that way you can always get a new stack when needed (== each
> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
> find (or create) a multi-page free area, and (fragmentation being what it
> is, and Linux routinely running for months at a time) you are in a whole
> new world of pain.

So people should really be asking for a PAGE_SIZE = 8k option ;)

Sorry,

-- Steve

Re: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2005-12-16 at 15:42 -0300, Horst von Brand wrote:
> > linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
> > 
> > [...]
> > 
> > > Throughout the past two years of 4k stack-wars, I never heard why
> > > such a small stack was needed (not wanted, needed). It seems that
> > > everybody "knows" that smaller is better and most everybody thinks
> > > that one page in ix86 land is "optimum". However I don't think
> > > anybody ever even tried to analyze what was better from a technical
> > > perspective. Instead it's been analyzed as religious dogma, i.e.,
> > > keep the stack small, it will prevent idiots from doing bad things.
> > 
> > OK, so here goes again...
> > 
> > The kernel stack has to be contiguous in /physical/ memory. Keep the stack
> > /one/ page, that way you can always get a new stack when needed (== each
> > fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
> > find (or create) a multi-page free area, and (fragmentation being what it
> > is, and Linux routinely running for months at a time) you are in a whole
> > new world of pain.

> So people should really be asking for a PAGE_SIZE = 8k option ;)

On i386 is is either 4KiB or 4MiB. Guess what I prefer...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

Horst von Brand wrote:

>>So people should really be asking for a PAGE_SIZE = 8k option ;)
>>    
>>
>
>On i386 is is either 4KiB or 4MiB. Guess what I prefer...
>  
>
Well, you can always use 8k pages - by setting PAGE_SIZE to 8k
and always set up the real 4k pages in pairs.  Wheter we want to do this
is another issue - but it is simple enough and avoids fragmentation.

Helge Hafting

Re: [2.6 patch] i386: always use 4k stacks

[linux-os (Dick Johnson)]

On Fri, 16 Dec 2005, Horst von Brand wrote:

> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
>
> [...]
>
>> Throughout the past two years of 4k stack-wars, I never heard why
>> such a small stack was needed (not wanted, needed). It seems that
>> everybody "knows" that smaller is better and most everybody thinks
>> that one page in ix86 land is "optimum". However I don't think
>> anybody ever even tried to analyze what was better from a technical
>> perspective. Instead it's been analyzed as religious dogma, i.e.,
>> keep the stack small, it will prevent idiots from doing bad things.
>
> OK, so here goes again...
>
> The kernel stack has to be contiguous in /physical/ memory. Keep the stack
> /one/ page, that way you can always get a new stack when needed (== each
> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have to
> find (or create) a multi-page free area, and (fragmentation being what it
> is, and Linux routinely running for months at a time) you are in a whole
> new world of pain.

The interrupt stack needs to be non-paged. Are you sure the user-stacks
need to be 'physical', non-paged too? If so, that's probably the
problem. All addresses accessed by the CPUs in the kernel are virtual
which means one needs some mapping anyway.

So, why can't one map non-contiguous pages into the kernel-user-stack?
That entry-into-the-kernel stack is the one that's giving everybody
fits because it needs to remain allocated, even for sleeping tasks.

If it was virtual, built just like other data, it could be made up
from any available RAM and, in the case of a preemptive kernel,
even swapped!

In that case, the total amount of real RAM you actually need
is defined only by the number of concurrent tasks in a preemptive
kernel, plus the page(s) for the interrupt stack. That's far lower
than the 'N' pages times everybody who forked and slept, which is
what we seem to have now.

FYI, there is nothing wrong with a 2-level stack, i.e., the
system-call occurs on the interrupt stack, then the user-kernel
stack gets allocated from paged RAM.

Now I know this isn't VMS, but in VMS we didn't have anything
that really needed to be contiguous except for the interrupt
stack (which was arbitrarily 64k). And on VAXen the pages were
tiny 512 things so you really need to use paged RAM for just
about everything.

> --
> Dr. Horst H. von Brand                   User #22616 counter.li.org
> Departamento de Informatica                     Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria              +56 32 654239
> Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: [2.6 patch] i386: always use 4k stacks

[David Lang]

On Fri, 16 Dec 2005, linux-os (Dick Johnson) wrote:

> On Fri, 16 Dec 2005, Horst von Brand wrote:
>
>> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
>>
>> [...]
>>
>>> Throughout the past two years of 4k stack-wars, I never heard why
>>> such a small stack was needed (not wanted, needed). It seems that
>>> everybody "knows" that smaller is better and most everybody thinks
>>> that one page in ix86 land is "optimum". However I don't think
>>> anybody ever even tried to analyze what was better from a technical
>>> perspective. Instead it's been analyzed as religious dogma, i.e.,
>>> keep the stack small, it will prevent idiots from doing bad things.
>>
>> OK, so here goes again...
>>
>> The kernel stack has to be contiguous in /physical/ memory. Keep the
> stack
>> /one/ page, that way you can always get a new stack when needed (==
> each
>> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have
> to
>> find (or create) a multi-page free area, and (fragmentation being what
> it
>> is, and Linux routinely running for months at a time) you are in a
> whole
>> new world of pain.
>
> The interrupt stack needs to be non-paged. Are you sure the user-stacks
> need to be 'physical', non-paged too? If so, that's probably the
> problem. All addresses accessed by the CPUs in the kernel are virtual
> which means one needs some mapping anyway.

actually, the kernel always uses real addresses, userspace uses virtual 
addresses.

This came up recently with the page tables, Linus said that he was 
absolutly opposed to adding the complication and overhead of changine the 
kernel to user virtual addresses instead of real addresses for it's data 
structures. it would add an extra level of redirection to just about every 
memory access (which also means an additional load on the cache to store 
the mapping info to resolve this redirection). The performance hit for 
this would be considerable.

David Lang

Re: [2.6 patch] i386: always use 4k stacks

[linux-os (Dick Johnson)]

On Fri, 16 Dec 2005, David Lang wrote:

> On Fri, 16 Dec 2005, linux-os (Dick Johnson) wrote:
>
>> On Fri, 16 Dec 2005, Horst von Brand wrote:
>>
>>> linux-os \(Dick Johnson\) <linux-os@analogic.com> wrote:
>>>
>>> [...]
>>>
>>>> Throughout the past two years of 4k stack-wars, I never heard why
>>>> such a small stack was needed (not wanted, needed). It seems that
>>>> everybody "knows" that smaller is better and most everybody thinks
>>>> that one page in ix86 land is "optimum". However I don't think
>>>> anybody ever even tried to analyze what was better from a technical
>>>> perspective. Instead it's been analyzed as religious dogma, i.e.,
>>>> keep the stack small, it will prevent idiots from doing bad things.
>>>
>>> OK, so here goes again...
>>>
>>> The kernel stack has to be contiguous in /physical/ memory. Keep the
>> stack
>>> /one/ page, that way you can always get a new stack when needed (==
>> each
>>> fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have
>> to
>>> find (or create) a multi-page free area, and (fragmentation being what
>> it
>>> is, and Linux routinely running for months at a time) you are in a
>> whole
>>> new world of pain.
>>
>> The interrupt stack needs to be non-paged. Are you sure the user-stacks
>> need to be 'physical', non-paged too? If so, that's probably the
>> problem. All addresses accessed by the CPUs in the kernel are virtual
>> which means one needs some mapping anyway.
>
> actually, the kernel always uses real addresses, userspace uses virtual
> addresses.
>

No. Hint: What is PAGE_OFFSET?
Everything the CPU executes/reads/writes is translated from physical (bus)
addresses to virtual addresses.

What you may have heard or read is that the address-space that the
kernel uses for its code and resident data has fixed translation tables
which means one doesn't have to scan a bunch of tables to locate the
bus address, given the virtual address.

physical_address = virtual_address  - PAGE_OFFSET;
virtual_address  = physical_address + PAGE_OFFSET;

This is totally an artifact of how the page-tables are set up.

> This came up recently with the page tables, Linus said that he was
> absolutly opposed to adding the complication and overhead of changine the
> kernel to user virtual addresses instead of real addresses for it's data
> structures. it would add an extra level of redirection to just about every
> memory access (which also means an additional load on the cache to store
> the mapping info to resolve this redirection). The performance hit for
> this would be considerable.
>
> David Lang
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

linux-os (Dick Johnson) wrote:

>On Thu, 15 Dec 2005, Lee Revell wrote:
>
>  
>
>>On Thu, 2005-12-15 at 14:46 -0700, Jeff V. Merkey wrote:
>>    
>>
>>>Lee Revell wrote:
>>>
>>>      
>>>
>>>>On Thu, 2005-12-15 at 14:07 -0700, Jeff V. Merkey wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>When you are on the phone with an irrate customer at 2:00 am in the
>>>>>morning, and just turning off your broken 4K stack fix
>>>>>and getting the customer running matters.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Bugzilla link please.  Otherwise STFU.
>>>>
>>>>
>>>>        
>>>>
>>>??????
>>>
>>>Jeff
>>>      
>>>
>>You imply that your customer's problem was due to a kernel bug triggered
>>by CONFIG_4KSTACKS.  I am asking you to provide a link to the bug report
>>or get lost.
>>
>>Lee
>>    
>>
>
>Throughout the past two years of 4k stack-wars, I never heard why
>such a small stack was needed (not wanted, needed). It seems that
>everybody "knows" that smaller is better and most everybody thinks
>that one page in ix86 land is "optimum". However I don't think
>anybody ever even tried to analyze what was better from a technical
>perspective. Instead it's been analyzed as religious dogma, i.e.,
>keep the stack small, it will prevent idiots from doing bad things.
>
>I'm fairly sure that if you started from scratch and decided to
>write a new operating system, your choice of a stack-size would
>probably be something like 64k. I have no clue why somebody
>decided to use a 4k stack and force their choice upon others.
>And, yes, I am well aware that each system-call requires a
>seperate stack upon entry and it even needs to keep that stack
>while sleeping.
>  
>
No.  If writing an os from scratch, then using 4k stacks would
be absolutely trivial.  The problems now happens only because
we're switching away from the 8k stacks people were used to having.
Design with 4k stacks from the start, and you'll see people writing
code with the assumption that they can't stick more than a handful
of ints/pointers on the stack.

If you design with 64k stacks then people _use_ that memory, and
soon you hear someone wanting 128k stacks to be "safe".  That
way you end up with windows.  Note that 64k is 16 pages, and they
have to be _consecutive_.  It don't take much fragmentation before
you can't get that many consecutive pages - you can easily have 3/4 of your
memory unused, ready to be taken, but still be unable to get 16 
consecutive pages.

To see this - create a small kernel module that tries to allocate 64k
of consecutive memory when loaded.  Try loading it after a few days
of normal use, and see how often your server fails to do it.

Helge Hafting

Re: [2.6 patch] i386: always use 4k stacks

[Ray Lee]

(Man, I've been holding my tongue on this conversation for a while,
but it seems my better angels have deserted me.)

On 12/15/05, Lee Revell <rlrevell@joe-job.com> wrote:
> Bugzilla link please.

No, that's not how failure engineering is done. A guy designing a
bridge doesn't cut all the supports back to the bare minimum just to
save money because his design says that the remaining metal should be
strong enough. If you can't prove it, and it's a safety issue
(continuing my analogy in the physical world), then you engineer for
failure. Can you handle all occurrences? No, a hurricane Katrina comes
along every once in a while. Can you weather more than you did before?
Yes. In the meantime, their are fewer poor sods falling off the bridge
that have to open a bugzilla report.

The world of software is no different. If someone wants to remove the
8k stacks option, they'd better prove that they're making my servers
more reliable. I've seen zero arguments for why 8k stacks is unviable.
(I've also wondered why we can't just have IRQ stacks plus 8k thread
stacks -- seemingly the best of both worlds) Instead, what I've seen
is that we have coders who don't like the idea of any non-order-zero
allocations taking place, because big systems running poorly coded
Java apps with massive threading can hit problems with allocations
from time to time.

The answer for that is the same answer the kernel community usually
gives about poorly designed userspace applications: rewrite them.

I'm quite open to being proved wrong. If someone has a counter case
they can toss forth, please do so. Systems taking lots of interrupts?
Then how about 8k + IRQ stacks? With a counterexample I'll gladly
concede that I'm an ignorant slut[*] -- excuse me, Saturday Night Live
flashbacks -- an ignorant git, and shut up. ([*] is only half right,
I'm not all that ignorant).

If someone doesn't show a counter case, then may I suggest people
consider the possibility that this is not proper engineering. Prove
it, or provide a safety blanket. But don't yank the blanket without
proving the lack of problem.

Ray

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

Ray Lee wrote:

>(Man, I've been holding my tongue on this conversation for a while,
>but it seems my better angels have deserted me.)
>
>On 12/15/05, Lee Revell <rlrevell@joe-job.com> wrote:
>  
>
>>Bugzilla link please.
>>    
>>
>
>No, that's not how failure engineering is done. A guy designing a
>bridge doesn't cut all the supports back to the bare minimum just to
>save money because his design says that the remaining metal should be
>strong enough. If you can't prove it, and it's a safety issue
>(continuing my analogy in the physical world), then you engineer for
>failure. Can you handle all occurrences? No, a hurricane Katrina comes
>along every once in a while. Can you weather more than you did before?
>Yes. In the meantime, their are fewer poor sods falling off the bridge
>that have to open a bugzilla report.
>  
>
This is quite different - you know much better what stack loads
the kernel may get into.  A bridge gets all sorts of weather,
with the very extreme cases occuring now and then.  With the
kernel, you can look at the code and determine the maximum
possible stack depth that can ever occur. It won't get deeper
even in some very rare case.


>The world of software is no different. If someone wants to remove the
>8k stacks option, they'd better prove that they're making my servers
>more reliable. I've seen zero arguments for why 8k stacks is unviable.
>  
>
Well, would you like the kernel to kill your webserver (or whatever
important app) because it attempted to fork at a time where
no two consecutive pages could be found?   That happens
occationally in real life - with 8k stack.  Going to 12k stack, 16k stacks,
or (shudder) 64 stacks would make that much worse than it
is today.

>(I've also wondered why we can't just have IRQ stacks plus 8k thread
>stacks -- seemingly the best of both worlds) Instead, what I've seen
>is that we have coders who don't like the idea of any non-order-zero
>allocations taking place, because big systems running poorly coded
>Java apps with massive threading can hit problems with allocations
>from time to time.
>  
>
You don't need big threaded apps for this to happen.  All
you need is a handful of forking apps and memory
fragmentation.  Many common server apps (web, mail, fileserver,...)
tend to use forking.  Massively threaded apps like 4k stacks simply
because that saves 4k for each of the many threads.

>The answer for that is the same answer the kernel community usually
>gives about poorly designed userspace applications: rewrite them.
>
>I'm quite open to being proved wrong. If someone has a counter case
>they can toss forth, please do so. Systems taking lots of interrupts?
>Then how about 8k + IRQ stacks? With a counterexample I'll gladly
>concede that I'm an ignorant slut[*] -- excuse me, Saturday Night Live
>flashbacks -- an ignorant git, and shut up. ([*] is only half right,
>I'm not all that ignorant).
>
>If someone doesn't show a counter case, then may I suggest people
>consider the possibility that this is not proper engineering. Prove
>it, or provide a safety blanket. But don't yank the blanket without
>proving the lack of problem.
>  
>
Well, failing order-1 allocations is _the_ counterexample.  IT
never happens with 4k stacks unless you run totally out of
memory, and then nothing can save you.

Helge Hafting

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Thu, Dec 15, 2005 at 11:30:00PM +0100, Adrian Bunk wrote:

 > An how many weird crashes with _different_ causes have you seen?
 > It could be that there are only _very_ few problems that noone really 
 > debugs brcause disabling 4k stacks fixes the issue.

the block layer issue that Neil had patches for was the only one
that rings any bells for me[*] (and the only one in Fedora bugzilla
that anyone has actually hit -- and that's 2-3 people out of
a *lot* of users).

		Dave

[*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
for a long time -- people were reporting overflows there before we
enabled 4K stacks.

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Thu, Dec 15, 2005 at 06:15:38PM -0500, Dave Jones wrote:
> On Thu, Dec 15, 2005 at 11:30:00PM +0100, Adrian Bunk wrote:
> 
>  > An how many weird crashes with _different_ causes have you seen?
>  > It could be that there are only _very_ few problems that noone really 
>  > debugs brcause disabling 4k stacks fixes the issue.
> 
> the block layer issue that Neil had patches for was the only one
> that rings any bells for me[*] (and the only one in Fedora bugzilla
> that anyone has actually hit -- and that's 2-3 people out of
> a *lot* of users).

Neil's patch is required, and since it's not in 2.6.15-rc we might still 
get bug reports with 4k stacks that are fixed by his patch.

Do we have any bug reports due to 4k stacks against -mm since Neil's 
patch was included?

People were able to convince me in the past to delay my patch to always 
use 4k stacks by pointing to unsolved problems (or I pointed them like 
in the reiser4 case) - and these were constructive delays since the code 
was fixed. So if someone wants to convince me that it's too early for my 
patch, simply send me some pointers to 4k stack issues still present in 
a recent -mm.  :-)

Hm, I just found two serious stack usage regressions in 2.6.15-rc (bug 
report will be in a separate email), but allocating arrays with more 
than 2000 elements on the stack is always wrong in the kernel 
independent of the stack size...

> 		Dave
> 
> [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
> for a long time -- people were reporting overflows there before we
> enabled 4K stacks.

I remember someone from the XFS maintainers (Nathan?) saying they 
believe having solved all XFS stack issues.

If there are any XFS issues left, do you have a pointer to them?

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] i386: always use 4k stacks

[Dave Jones]

On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:

 > > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
 > > for a long time -- people were reporting overflows there before we
 > > enabled 4K stacks.
 > 
 > I remember someone from the XFS maintainers (Nathan?) saying they 
 > believe having solved all XFS stack issues.
 > 
 > If there are any XFS issues left, do you have a pointer to them?

The last one I saw may have been actually been more related
to the block layer problem. iirc that was a user NFS exporting
XFS on a raid1 array.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Neil Brown]

On Thursday December 15, davej@redhat.com wrote:
> On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:
> 
>  > > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
>  > > for a long time -- people were reporting overflows there before we
>  > > enabled 4K stacks.
>  > 
>  > I remember someone from the XFS maintainers (Nathan?) saying they 
>  > believe having solved all XFS stack issues.
>  > 
>  > If there are any XFS issues left, do you have a pointer to them?
> 
> The last one I saw may have been actually been more related
> to the block layer problem. iirc that was a user NFS exporting
> XFS on a raid1 array.

Yeh, I've noticed that nfsd seems to figure often in these.  As nfsd
lives on the same (in-kernel) stack as the filesystem and device
drives, it will add a couple of hundred bytes to the call trace.

A typical nfsd call trace is
 nfsd -> svc_process -> nfsd_dispatch -> nfsd3_proc_write ->
   nfsd_write ->nfsd_vfs_write -> vfs_writev

(errr. nfsd_vfs_write is inline, large, and called twice, that ain't
good)

These add up to over 300 bytes on the stack.
Looking at each of these, I see that nfsd_write (which includes
 nfsd_vfs_write) contributes 0x8c to stack usage itself!!

It turns out this is because it puts a 'struct iattr' on the stack so
it can kill suid if needed.  The following patch saves about 50 bytes
off the stack in this call path.

I sometimes wish that gcc could be told to optimise for stack usage -
a lot of variables on the stack are dead at some call points, yet they
stay there using space anyway.  The only way to save this space seem
to be to move the code which uses those variable into a separate
function, but we really shouldn't *have* to do these optimisations by
hand!

NeilBrown

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./fs/nfsd/vfs.c |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff ./fs/nfsd/vfs.c~current~ ./fs/nfsd/vfs.c
--- ./fs/nfsd/vfs.c~current~	2005-12-12 16:00:40.000000000 +1100
+++ ./fs/nfsd/vfs.c	2005-12-16 13:48:31.000000000 +1100
@@ -869,6 +869,16 @@ out:
 	return err;
 }
 
+static void kill_suid(struct dentry *dentry)
+{
+	struct iattr	ia;
+	ia.ia_valid = ATTR_KILL_SUID | ATTR_KILL_SGID;
+
+	down(&dentry->d_inode->i_sem);
+	notify_change(dentry, &ia);
+	up(&dentry->d_inode->i_sem);
+}
+
 static inline int
 nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file *file,
 				loff_t offset, struct kvec *vec, int vlen,
@@ -922,14 +932,8 @@ nfsd_vfs_write(struct svc_rqst *rqstp, s
 	}
 
 	/* clear setuid/setgid flag after write */
-	if (err >= 0 && (inode->i_mode & (S_ISUID | S_ISGID))) {
-		struct iattr	ia;
-		ia.ia_valid = ATTR_KILL_SUID | ATTR_KILL_SGID;
-
-		down(&inode->i_sem);
-		notify_change(dentry, &ia);
-		up(&inode->i_sem);
-	}
+	if (err >= 0 && (inode->i_mode & (S_ISUID | S_ISGID)))
+		kill_suid(dentry);
 
 	if (err >= 0 && stable) {
 		static ino_t	last_ino;

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Fri, Dec 16, 2005 at 01:56:58PM +1100, Neil Brown wrote:

 > It turns out this is because it puts a 'struct iattr' on the stack so
 > it can kill suid if needed.  The following patch saves about 50 bytes
 > off the stack in this call path.

See! it *was* worth Adrian bringing up the "kill 8kb stacks" patch again :-)

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Fri, Dec 16, 2005 at 01:56:58PM +1100, Neil Brown wrote:
> On Thursday December 15, davej@redhat.com wrote:
> > On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:
> > 
> >  > > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
> >  > > for a long time -- people were reporting overflows there before we
> >  > > enabled 4K stacks.
> >  > 
> >  > I remember someone from the XFS maintainers (Nathan?) saying they 
> >  > believe having solved all XFS stack issues.
> >  > 
> >  > If there are any XFS issues left, do you have a pointer to them?
> > 
> > The last one I saw may have been actually been more related
> > to the block layer problem. iirc that was a user NFS exporting
> > XFS on a raid1 array.
> 
> Yeh, I've noticed that nfsd seems to figure often in these.  As nfsd
> lives on the same (in-kernel) stack as the filesystem and device
> drives, it will add a couple of hundred bytes to the call trace.
> 
> A typical nfsd call trace is
>  nfsd -> svc_process -> nfsd_dispatch -> nfsd3_proc_write ->
>    nfsd_write ->nfsd_vfs_write -> vfs_writev
> 
> (errr. nfsd_vfs_write is inline, large, and called twice, that ain't
> good)

The nfsd code uses inline in too many places.

gcc can figure out itself that static functions called only once should 
be inline (except currently on i386 due to no-unit-at-a-time, see 
below).

> These add up to over 300 bytes on the stack.
> Looking at each of these, I see that nfsd_write (which includes
>  nfsd_vfs_write) contributes 0x8c to stack usage itself!!
> 
> It turns out this is because it puts a 'struct iattr' on the stack so
> it can kill suid if needed.  The following patch saves about 50 bytes
> off the stack in this call path.
>...

This works currently on i386 (and only on i386) because we are using 
-fno-unit-at-a-time there.

In the medium-term, we want to get rid of no-unit-at-a-time because this 
makes the code both bigger and slower, and I'm therefore not a big fan 
of this kind of workarounds.

If this struct is really a problem (which I doubt considering it's 
size), I'd prefer it being kmalloc'ed.

> NeilBrown
>...

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] i386: always use 4k stacks

[Horst von Brand]

Adrian Bunk <bunk@stusta.de> wrote:
> On Fri, Dec 16, 2005 at 01:56:58PM +1100, Neil Brown wrote:

[...]

> gcc can figure out itself that static functions called only once should 
> be inline (except currently on i386 due to no-unit-at-a-time, see 
> below).
> 
> > These add up to over 300 bytes on the stack.
> > Looking at each of these, I see that nfsd_write (which includes
> >  nfsd_vfs_write) contributes 0x8c to stack usage itself!!
> > 
> > It turns out this is because it puts a 'struct iattr' on the stack so
> > it can kill suid if needed.  The following patch saves about 50 bytes
> > off the stack in this call path.
> >...

And if you set up a compound literal for the task then? It is just used to
shove data into the called function.

My short test case (attached) has a smaller stack with the compound
literal (gcc-4.1, Fedora rawhide on i686), and IMHO it is clearer what is
going on here.

> This works currently on i386 (and only on i386) because we are using 
> -fno-unit-at-a-time there.
> 
> In the medium-term, we want to get rid of no-unit-at-a-time because this 
> makes the code both bigger and slower, and I'm therefore not a big fan 
> of this kind of workarounds.
> 
> If this struct is really a problem (which I doubt considering it's 
> size), I'd prefer it being kmalloc'ed.

Nodz.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[Neil Brown]

On Friday December 16, bunk@stusta.de wrote:
> 
> The nfsd code uses inline in too many places.

Does it?
Most of the uses are either
 - truly tiny bits of code
 - code that is used only once which, as you as, will not currently 
   be auto-inlined on i386, so we do it by hand.

An exception is some of the xdr code.
If I 
  #define inline
in nfs3xdr.c, the nfsd.o changes from 
   text    data     bss     dec     hex filename
  76132    3464    2408   82004   14054 ../mm-i386/fs/nfsd/nfsd.o
to
   text    data     bss     dec     hex filename
  72452    3464    2408   78324   131f4 ../mm-i386/fs/nfsd/nfsd.o
which is probably a win.

Is that what you were referring to?

> 
> If this struct is really a problem (which I doubt considering it's 
> size), I'd prefer it being kmalloc'ed.

It's hard to *know* if it is a problem, but I am conscious that nfsd
adds measurably to stack depth for filesystem paths, and probably
isn't measured nearly as often.
It's true that 50 bytes out of 4K isn't a lot, but wastage that can be
avoided, should be avoided.

NeilBrown

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Mon, Dec 19, 2005 at 11:45:24AM +1100, Neil Brown wrote:
> On Friday December 16, bunk@stusta.de wrote:
> > 
> > The nfsd code uses inline in too many places.
> 
> Does it?
> Most of the uses are either
>  - truly tiny bits of code

That's OK if they stay tiny and don't grow as time passes by.

>  - code that is used only once which, as you as, will not currently 
>    be auto-inlined on i386, so we do it by hand.

That's OK if it isn't forgotten to un-inline them when they get more 
callers.

Unfortunately, people often don't check whether an "inline" is still 
appropriate when the code evolves.

Unless this is an extreme hot path, it's therefore IMHO not a good idea 
to use "inline" in such cases.

Additionally, it's a medium-term goal for me to re-enable unit-at-a-time 
on i386 for recent gcc's.

> An exception is some of the xdr code.
> If I 
>   #define inline
> in nfs3xdr.c, the nfsd.o changes from 
>    text    data     bss     dec     hex filename
>   76132    3464    2408   82004   14054 ../mm-i386/fs/nfsd/nfsd.o
> to
>    text    data     bss     dec     hex filename
>   72452    3464    2408   78324   131f4 ../mm-i386/fs/nfsd/nfsd.o
> which is probably a win.
> 
> Is that what you were referring to?

I didn't had one specific example in mind, but yes this seems to be an 
example for inline's that might have been reasonable at one time in the 
past, but are no longer today.

> > If this struct is really a problem (which I doubt considering it's 
> > size), I'd prefer it being kmalloc'ed.
> 
> It's hard to *know* if it is a problem, but I am conscious that nfsd
> adds measurably to stack depth for filesystem paths, and probably
> isn't measured nearly as often.
> It's true that 50 bytes out of 4K isn't a lot, but wastage that can be
> avoided, should be avoided.

"make checkstack" tells that nfsd_vfs_write is below 100 bytes of stack 
usage. So even calling 30 such functions would not get you above
3 kB stack usage.

It's also interesting that according to Jörn Engel's static analysis of 
call paths in kernel 2.6.11 [1], the string "nfs" does occur in neither 
any of the functions involved in call paths with > 2 kB stack usage, nor 
in any recursive call paths.

It's OK to use some bytes from the stack, and you haven't yet convinced 
me that the code you are responsible for is using too much stack.  ;-)

> NeilBrown

cu
Adrian

[1] http://wh.fh-wedel.de/~joern/stackcheck.2.6.11

-- 

       "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] i386: always use 4k stacks

[Jörn Engel]

On Mon, 19 December 2005 02:34:29 +0100, Adrian Bunk wrote:
> On Mon, Dec 19, 2005 at 11:45:24AM +1100, Neil Brown wrote:
> > 
> > It's hard to *know* if it is a problem, but I am conscious that nfsd
> > adds measurably to stack depth for filesystem paths, and probably
> > isn't measured nearly as often.
> > It's true that 50 bytes out of 4K isn't a lot, but wastage that can be
> > avoided, should be avoided.
> 
> "make checkstack" tells that nfsd_vfs_write is below 100 bytes of stack 
> usage. So even calling 30 such functions would not get you above
> 3 kB stack usage.
> 
> It's also interesting that according to Jörn Engel's static analysis of 
> call paths in kernel 2.6.11 [1], the string "nfs" does occur in neither 
> any of the functions involved in call paths with > 2 kB stack usage, nor 
> in any recursive call paths.
> 
> It's OK to use some bytes from the stack, and you haven't yet convinced 
> me that the code you are responsible for is using too much stack.  ;-)

Well, my metrics show the worst non-recursive paths and recursions
only.  The case at hand is a relatively innocent path on its own, but
is stacked on top of one of the recursions.

Therefore, if my tool could make more sense of recursions and f.e. see
that raid over raid is unlikely, but nfsd over xfs over raid over
block is likely, nfsd would definitely show up.  Recursions are the
hard problem to worry about.

Don't blame Neil for my tool being stupid. :)

Jörn

-- 
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty

Re: [2.6 patch] i386: always use 4k stacks

[Nathan Scott]

On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:
> ...
> > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
> > for a long time -- people were reporting overflows there before we
> > enabled 4K stacks.
> 
> I remember someone from the XFS maintainers (Nathan?) saying they 
> believe having solved all XFS stack issues.

We don't know of any remaining issues...

> If there are any XFS issues left, do you have a pointer to them?

...so I was curious to see these too, since we've never had any
reported from Dave / anyone else @RH.

cheers.

-- 
Nathan

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Fri, Dec 16, 2005 at 12:15:19PM +1100, Nathan Scott wrote:
 > On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:
 > > ...
 > > > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
 > > > for a long time -- people were reporting overflows there before we
 > > > enabled 4K stacks.
 > > 
 > > I remember someone from the XFS maintainers (Nathan?) saying they 
 > > believe having solved all XFS stack issues.
 > 
 > We don't know of any remaining issues...
 > 
 > > If there are any XFS issues left, do you have a pointer to them?
 > 
 > ...so I was curious to see these too, since we've never had any
 > reported from Dave / anyone else @RH.

When they've come up in bugzilla, I've pointed them at the xfs
mailing lists. As these folks can reproduce the problems, it seemed
pointless to play middle-man.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Zwane Mwaikambo]

On Thu, 15 Dec 2005, Adrian Bunk wrote:

> On Thu, Dec 15, 2005 at 02:00:13PM -0800, Andrew Morton wrote:
> 
> > Supporting 8k stacks is a small amount of code and nobody has seen a need
> > to make changes in there for quite a long time.  So there's little cost to
> > keeping the existing code.
> > 
> > And the existing code is useful:
> > 
> > a) people can enable it to confirm that their weird crash was due to a
> >    stack overflow.
> > 
> > b) If I was going to put together a maximally-stable kernel for a
> >    complex server machine, I'd select 8k stacks.  We're still just too
> >    squeezy, and we've had too many relatively-recent overflows, and there
> >    are still some really deep callpaths in there.
> 
> a1) People turn off 4k stacks and never report the problem / noone 
>     really debugs and fixes the reported problem.
> 
> Me threatening people with enabling 4k stacks for everyone already 
> resulted in several fixes.

How about this, we apply this patch and perhaps add some debug option to 
enable 8k by changing THREAD_SIZE. This way we have the seperate interrupt 
stacks and 8k stacks for when someone suspects a stack overflow.

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Thu, Dec 15, 2005 at 05:49:45PM -0800, Zwane Mwaikambo wrote:
> On Thu, 15 Dec 2005, Adrian Bunk wrote:
> 
> > On Thu, Dec 15, 2005 at 02:00:13PM -0800, Andrew Morton wrote:
> > 
> > > Supporting 8k stacks is a small amount of code and nobody has seen a need
> > > to make changes in there for quite a long time.  So there's little cost to
> > > keeping the existing code.
> > > 
> > > And the existing code is useful:
> > > 
> > > a) people can enable it to confirm that their weird crash was due to a
> > >    stack overflow.
> > > 
> > > b) If I was going to put together a maximally-stable kernel for a
> > >    complex server machine, I'd select 8k stacks.  We're still just too
> > >    squeezy, and we've had too many relatively-recent overflows, and there
> > >    are still some really deep callpaths in there.
> > 
> > a1) People turn off 4k stacks and never report the problem / noone 
> >     really debugs and fixes the reported problem.
> > 
> > Me threatening people with enabling 4k stacks for everyone already 
> > resulted in several fixes.
> 
> How about this, we apply this patch and perhaps add some debug option to 
> enable 8k by changing THREAD_SIZE. This way we have the seperate interrupt 
> stacks and 8k stacks for when someone suspects a stack overflow.

You can always manually change THREAD_SIZE using a text editor.

My count of bug reports for problems with in-kernel code with 4k stacks 
after Neil's patch went into -mm is still at 0.

Either there are no problems left or noone pays attention to them since 
disabling 4k stacks "fixed" the problem. And not having an option makes 
it more likely that we get reports for and people interested in fixes 
for the latter.

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] i386: always use 4k stacks

[Diego Calleja]

El Thu, 15 Dec 2005 14:00:13 -0800,
Andrew Morton <akpm@osdl.org> escribió:


> Supporting 8k stacks is a small amount of code and nobody has seen a need
> to make changes in there for quite a long time.  So there's little cost to
> keeping the existing code.
> 
> And the existing code is useful:

Maybe this slighty different approach is better? 



Signed-off-by: Diego Calleja <diegocg@gmail.com>

Index: test/arch/i386/Kconfig.debug
===================================================================
--- test.orig/arch/i386/Kconfig.debug	2005-12-16 13:59:54.000000000 +0100
+++ test/arch/i386/Kconfig.debug	2005-12-16 14:03:27.000000000 +0100
@@ -42,15 +42,16 @@
 	  This results in a large slowdown, but helps to find certain types
 	  of memory corruptions.
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
+config 8KSTACKS
+	bool "Use 8Kb for kernel stacks instead of 4Kb"
 	depends on DEBUG_KERNEL
 	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
+	  If you say Y here the kernel will use a 8Kb stacksize for the
+	  kernel stack attached to each process/thread. This makes harder
+	  to overflow the stack, and it's used to debug possible stack
+	  overflow problems. Notice that this increases 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 disable IRQ stacks.
 
 config X86_FIND_SMP_CONFIG
 	bool
Index: test/arch/i386/kernel/irq.c
===================================================================
--- test.orig/arch/i386/kernel/irq.c	2005-12-16 13:59:54.000000000 +0100
+++ test/arch/i386/kernel/irq.c	2005-12-16 14:01:24.000000000 +0100
@@ -33,7 +33,7 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -55,7 +55,7 @@
 {	
 	/* high bits used in ret_from_ code */
 	int irq = regs->orig_eax & 0xff;
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
 #endif
@@ -76,7 +76,7 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
 
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
@@ -112,7 +112,7 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
 
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
Index: test/include/asm-i386/irq.h
===================================================================
--- test.orig/include/asm-i386/irq.h	2005-12-16 13:59:54.000000000 +0100
+++ test/include/asm-i386/irq.h	2005-12-16 14:04:05.000000000 +0100
@@ -27,7 +27,7 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
   extern void irq_ctx_init(int cpu);
   extern void irq_ctx_exit(int cpu);
 # define __ARCH_HAS_DO_SOFTIRQ
Index: test/include/asm-i386/module.h
===================================================================
--- test.orig/include/asm-i386/module.h	2005-12-16 13:59:54.000000000 +0100
+++ test/include/asm-i386/module.h	2005-12-16 14:04:36.000000000 +0100
@@ -64,8 +64,8 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
+#ifdef CONFIG_8KSTACKS
+#define MODULE_STACKSIZE "8KSTACKS "
 #else
 #define MODULE_STACKSIZE ""
 #endif
Index: test/include/asm-i386/thread_info.h
===================================================================
--- test.orig/include/asm-i386/thread_info.h	2005-12-16 13:59:54.000000000 +0100
+++ test/include/asm-i386/thread_info.h	2005-12-16 14:04:57.000000000 +0100
@@ -53,7 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
+#ifndef CONFIG_8KSTACKS
 #define THREAD_SIZE            (4096)
 #else
 #define THREAD_SIZE		(8192)

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Fri, Dec 16, 2005 at 02:10:02PM +0100, Diego Calleja wrote:
> El Thu, 15 Dec 2005 14:00:13 -0800,
> Andrew Morton <akpm@osdl.org> escribió:
> 
> 
> > Supporting 8k stacks is a small amount of code and nobody has seen a need
> > to make changes in there for quite a long time.  So there's little cost to
> > keeping the existing code.
> > 
> > And the existing code is useful:
> 
> Maybe this slighty different approach is better? 
>...

My count of bug reports for problems with 4k stacks after Neil's patch
went into -mm is still at 0.

Either there are no problems left or noone pays attention to them since 
disabling 4k stacks "fixed" the problem.

In both cases there's no reason against applying my patch.

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] i386: always use 4k stacks

[Diego Calleja]

El Fri, 16 Dec 2005 15:04:25 +0100,
Adrian Bunk <bunk@stusta.de> escribió:

> My count of bug reports for problems with 4k stacks after Neil's patch
> went into -mm is still at 0.
> 
> Either there are no problems left or noone pays attention to them since 
> disabling 4k stacks "fixed" the problem.
> 
> In both cases there's no reason against applying my patch.

I know, but there's too much resistance to the "pure" 4kb patch. The
8 KB patch does the same thing (enables 4kb stacks)  and at the same
time the 8kb groupies can't flamewar you for it, it covers akpm's
concerns, it puts some pressure on the ndiswrapper guys and leaves
time for the broadcom driver developers to finish, merge and push
to the distributions their driver. The 8kb config option can be
removed in the future when we're sure that it's 100% safe (neil
brown's patch isn''t a good sign). It makes every happy IMO ;)

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 16, 2005, at 10:35, Diego Calleja wrote:
> I know, but there's too much resistance to the "pure" 4kb patch.

I have yet to see any resistance to the 4Kb patch this time around  
that was not "*whine* don't break my ndiswrapper plz".   There are  
extremely few remaining 4kb stack bugs, and 4k stacks have a sizeable  
list of technical advantages.


> The 8 KB patch does the same thing (enables 4kb stacks)

The point is to force it in -mm so most people can't just disable it  
because it fixes their problem.  We want 8k stacks to go away, and  
the only way to get out the last issues before sending to mainline is  
by forcing it in -mm.


> and at the same time the 8kb groupies can't flamewar you for it

This matter how?


> it covers akpm's concerns

I get the impression that they are already sufficiently addressed,  
although Andrew should feel free to correct me if I'm wrong :-D.


> it puts some pressure on the ndiswrapper guys

And removing 8kb all-together doesn't do this?


> and leaves time for the broadcom driver developers to finish, merge  
> and push to the distributions their driver

It's working partially now.  This is the time when we should really  
try to force ndiswrapper junkies over to the driver to get it tested  
and bugfixed for inclusion.


> The 8kb config option can be removed in the future when we're sure  
> that it's 100% safe (neil brown's patch isn''t a good sign). It  
> makes every happy IMO ;)

We're not trying to get it removed from mainline (yet), just from - 
mm, which has never been anywhere close to 100% safe _anyways_.  If  
it breaks lots of things horribly, it will get reverted and  
development will continue as normal, but that's probably not going to  
be the case.

Cheers,
Kyle Moffett

--
Debugging is twice as hard as writing the code in the first place.   
Therefore, if you write the code as cleverly as possible, you are, by  
definition, not smart enough to debug it.
   -- Brian Kernighan

Re: [2.6 patch] i386: always use 4k stacks

[Michael Buesch]

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

On Friday 16 December 2005 16:49, you wrote:
> > and leaves time for the broadcom driver developers to finish, merge  
> > and push to the distributions their driver
> 
> It's working partially now.  This is the time when we should really  
> try to force ndiswrapper junkies over to the driver to get it tested  
> and bugfixed for inclusion.

Partially means:
- Connections on CCK Rates (802.11b) are stable,
  if the signal quality is good (you are close to the AP).
- No encryption support, yet (I am working on it, but it's
  a bit difficult)

Now, I want to test bcm43xx on 4k stacks. But only have a
ppc32 machine with such a broadcom card. ppc32 has 8k stacks.
How am I supposed to test the driver for 4kstack conformance?
Given this, why aren't there people working on 4kstacks for
ppc32? Is it not needed there, or did simply nobody care to
do this now?
Thanks for your nonflaming suggestions. ;)

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Gwe, 2005-12-16 at 17:23 +0100, Michael Buesch wrote:
> Now, I want to test bcm43xx on 4k stacks. But only have a
> ppc32 machine with such a broadcom card. ppc32 has 8k stacks.
> How am I supposed to test the driver for 4kstack conformance?

Unless you've been writing fairly careless code putting a lot of objects
on stack a driver is going to work fine with 4K stacks.

> Given this, why aren't there people working on 4kstacks for
> ppc32? Is it not needed there, or did simply nobody care to
> do this now?

AFAIK nobody is working on 4K stack for PPC32. I've no idea myself if it
is needed or useful there. In terms of debugging if your code exceeds a
4K stack you'll find out quite rapidly from x86 users. One thing the
seperate IRQ stacks mean is that stack overflows generally show up as
overflows and consistently rather than as weird crashes when timing
co-incides between your heavy stack usage and IRQ heavy stack usage, at
which point the mess is rarely repeatable or debuggable

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Fri, 2005-12-16 at 20:02 +0000, Alan Cox wrote:
> On Gwe, 2005-12-16 at 17:23 +0100, Michael Buesch wrote:
> > Now, I want to test bcm43xx on 4k stacks. But only have a
> > ppc32 machine with such a broadcom card. ppc32 has 8k stacks.
> > How am I supposed to test the driver for 4kstack conformance?
> 
> Unless you've been writing fairly careless code putting a lot of objects
> on stack a driver is going to work fine with 4K stacks.

there is also "make checkstack" that works on many architectures, and
lists offenders. If you're clean there it's very likely you're very
ok ;)

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Kyle Moffett wrote:

> I have yet to see any resistance to the 4Kb patch this time around
> that was not "*whine* don't break my ndiswrapper plz".   There are

I haven't seen anyone demanding others not to have 4k stacks; only requests
to leave 4k/8k stack option as it is. If _you_ want to have 4k stacks, you
already have that option. You are only pushing what you want on others and
bad mouthing people that are requesting the option to have either 4k or 8k
stacks.

> It's working partially now.  This is the time when we should really

ndiswrapper is used not just for broadcom. There are plenty of other
chipsets that don't even have a project started to write open source
driver.

> try to force ndiswrapper junkies over to the driver to get it tested
                           ^^^^^^^
Shame on you. Your last mail was a promise to be "more reserved". Even
otherwise, such profanities against a group of people are unwarranted.

To kernel developers: I have earlier requested if it is possible to create
threads with different stack sizes (e.g., 4k/8k/16k etc.) at run-time, ala
FreeBSD. In that case, one could chose whatever it is that fits their
needs. Any comments on this idea?

To those that depend on ndiswrapper to have wireless in Linux: A few days
ago I started working on NDIS implementation in user space. However, it
will take considerable time before this is usable. Moreover, I only have
hope with USB drivers. PCI/mini-PCI/PCMCIA drivers need to run interrupt
service routines, which can't be run in user space, so they won't work in
user space.

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Fri, 2005-12-16 at 13:18 -0500, Giridhar Pemmasani wrote:
> Kyle Moffett wrote:
> 
> > I have yet to see any resistance to the 4Kb patch this time around
> > that was not "*whine* don't break my ndiswrapper plz".   There are
> 
> I haven't seen anyone demanding others not to have 4k stacks; only requests
> to leave 4k/8k stack option as it is. 

in hindsight making this a config option was a mistake. Why? Because
we're not making every single patch we add to the kernel a config
option, nor should it be. Config options for drivers or expensive debug
options are fine, debug options for random patches... aren't really. To
be fair the config option was intended to be really temporary, like 1
kernel release, until it was sure there were no kinks. Oh well, there's
too many people moaning now about ndiswrapper that I fear we'll never
get rid of it.

And no I do not think a kernel with 9000 config options is still useful;
not every single trivial thing should be a config option.

Re: [2.6 patch] i386: always use 4k stacks

[Mike Snitzer]

On 12/16/05, Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 2005-12-16 at 13:18 -0500, Giridhar Pemmasani wrote:
> > Kyle Moffett wrote:
> >
> > > I have yet to see any resistance to the 4Kb patch this time around
> > > that was not "*whine* don't break my ndiswrapper plz".   There are
> >
> > I haven't seen anyone demanding others not to have 4k stacks; only requests
> > to leave 4k/8k stack option as it is.
>
> in hindsight making this a config option was a mistake. Why? Because
> we're not making every single patch we add to the kernel a config
> option, nor should it be. Config options for drivers or expensive debug
> options are fine, debug options for random patches... aren't really. To
> be fair the config option was intended to be really temporary, like 1
> kernel release, until it was sure there were no kinks. Oh well, there's
> too many people moaning now about ndiswrapper that I fear we'll never
> get rid of it.
>
> And no I do not think a kernel with 9000 config options is still useful;
> not every single trivial thing should be a config option.

You're using overly generalized assertions to try to convince others
that the configurability of a particularly important (to some, albeit
not you) config option is unnecessary.  4K vs 8K is hardly a "trivial"
configuration option of the Linux kernel.  At this point in time it
has not been sufficiently demonstrated that 4K "just works".

Taking a step back, I'm all for -mm being a 4K only tree to force the
issue; but even once all in-tree code is deemed 4K clean people still
may want to be extremely cautious by enabling 8K stacks (possibly
_with_ IRQ stacks).  Its merely a question of can/will Linux (or some
vendor) provide this level of stack overflow safety as is; or does one
need to patch the kernel to get the desired safety?  IF upstream
kernel.org doesn't even provide the knobs to ensure safety at all
costs (and vendors like Redhat have people at the helm who are
advocating 4K stacks in the "Enterprise" Linux kernel configurations
of the world) how does one get a Linux kernel that provides a sizable
safety net that is _SUPPORTED_ for true enterprise-grade applications?

Simply put 4K vs 8K is not as trivial a decision as you'd have people believe.

Mike

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> You're using overly generalized assertions to try to convince others

I'm no longer interested in arguing removing this thing. Too much
whining by ndiswrapper addicts [1].

> that the configurability of a particularly important (to some, albeit
> not you) config option is unnecessary.  4K vs 8K is hardly a "trivial"
> configuration option of the Linux kernel. 

Compared to many of the other changes that went in since 2.6.0? 4K
stacks is a minor change. There's no config option for 4 level
pagetables for example, and that's a far more invasive change in many
ways. 

>  At this point in time it
> has not been sufficiently demonstrated that 4K "just works".

Excuse me?
Fedora released 3 distributions with it enabled, and Red Hat uses it in
an enterprise distribution. That's a whopping lot of users right there
with a very wide range of workloads.

>  kernel to get the desired safety?  IF upstream
> kernel.org doesn't even provide the knobs to ensure safety at all
> costs (and vendors like Redhat have people at the helm who are
> advocating 4K stacks in the "Enterprise" Linux kernel configurations
> of the world) how does one get a Linux kernel that provides a sizable
> safety net that is _SUPPORTED_ for true enterprise-grade applications?

eh I don't know if you paid attention, but Red Hat Enterprise Linux 4
only has 4Kb stacks kernels... so that covers your supported true
enterprise-grade application thing. 

> Simply put 4K vs 8K is not as trivial a decision as you'd have people believe.

that's too simply put in fact, especially if you look at it
historically. It's a bit of irony that part of the reason 4K stacks was
developed was that the 2.4 kernels ran out of stack space for customers
occasionally (just as example look at lkml this week, there was a report
about such an overflow there as well). Remember that 4K+4K has more
stack space than the 4K+2K as 2.4 kernels have. Sure 2.6 bumped this to
5.5k/2.5k roughly in the "8K" case, but fundamentally the change to
4k/4k isn't all that big even inside 2.6. 

You can go on and keep painting this as a cowboy development, but it
really isn't....



[1] Yes addicts; binary drivers are in many ways similar to heroin;
they're really hard to get rid of for example and highly addictive, they
also cause some people to act like junkies-in-withdrawl when their
binary driver breaks, or when someone suggests breaking it.

Re: [2.6 patch] i386: always use 4k stacks

[Mike Snitzer]

Arjan,

I'm aware that RedHat has been shipping FC and RHEL kernels with 4K
stacks for some time.  The recent 4K stack fixes pretty much establish
that RedHat's early adoption of 4K stacks was a "cowbody development"
no?  I don't think RedHat kept similar 4K stack fixes from upstream,
so a bit of luck maybe?  I do agree that at this point the 4K-only
proposal is NOT an overly rash decision given continued adequate
vetting in -mm.  But even then there may be untested workloads that
expose stack issues.  Which is perfectly fine if users have the option
to use _supported_ alternate configs.

I got the sense that you were trying to paint me as something of a
closet "ndiswrapper addict".  Amusing and all but my motivations for
requesting continued options on the stack size are rooted in concerns
that long call chains can and still do result when running kernel.org
and RHEL4 kernels under particular workloads.  An example workload
being cluster filesystems that in a single call chain historically
_could_ leverage iptables + RPC (tcp) + DM (LVM) + etc.

Given Neil Brown's fix for the block layer these stack-heavy workloads
that included DM in the call chain need to be revisited.  However, the
savings associated with those particular fixes still may not leave
sufficient breathing room.  The logic that all users must NOW provide
workloads which undermine 4K stack viability otherwise the 8K option
will be completely removed _seems_ quite irrational (even though we
are _supposedly_ just talking about doing so in -mm).

All of us appreciate the desire to have Linux be more efficient and 4K
stacks will get us that.  If it comes with the cost of instability
under more exotic workloads then the bad outweighs the perceived good
of imposed 4K stacks.  With RHEL4 it would seem we're past the point
of no-return for supported 8K stacks.  I'm merely advocating upstream
give users the 8K+IRQ stack _options_ and set the default to 4K.

Mike


On 12/16/05, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > You're using overly generalized assertions to try to convince others
>
> I'm no longer interested in arguing removing this thing. Too much
> whining by ndiswrapper addicts [1].
>
> > that the configurability of a particularly important (to some, albeit
> > not you) config option is unnecessary.  4K vs 8K is hardly a "trivial"
> > configuration option of the Linux kernel.
>
> Compared to many of the other changes that went in since 2.6.0? 4K
> stacks is a minor change. There's no config option for 4 level
> pagetables for example, and that's a far more invasive change in many
> ways.
>
> >  At this point in time it
> > has not been sufficiently demonstrated that 4K "just works".
>
> Excuse me?
> Fedora released 3 distributions with it enabled, and Red Hat uses it in
> an enterprise distribution. That's a whopping lot of users right there
> with a very wide range of workloads.
>
> >  kernel to get the desired safety?  IF upstream
> > kernel.org doesn't even provide the knobs to ensure safety at all
> > costs (and vendors like Redhat have people at the helm who are
> > advocating 4K stacks in the "Enterprise" Linux kernel configurations
> > of the world) how does one get a Linux kernel that provides a sizable
> > safety net that is _SUPPORTED_ for true enterprise-grade applications?
>
> eh I don't know if you paid attention, but Red Hat Enterprise Linux 4
> only has 4Kb stacks kernels... so that covers your supported true
> enterprise-grade application thing.
>
> > Simply put 4K vs 8K is not as trivial a decision as you'd have people believe.
>
> that's too simply put in fact, especially if you look at it
> historically. It's a bit of irony that part of the reason 4K stacks was
> developed was that the 2.4 kernels ran out of stack space for customers
> occasionally (just as example look at lkml this week, there was a report
> about such an overflow there as well). Remember that 4K+4K has more
> stack space than the 4K+2K as 2.4 kernels have. Sure 2.6 bumped this to
> 5.5k/2.5k roughly in the "8K" case, but fundamentally the change to
> 4k/4k isn't all that big even inside 2.6.
>
> You can go on and keep painting this as a cowboy development, but it
> really isn't....
>
>
>
> [1] Yes addicts; binary drivers are in many ways similar to heroin;
> they're really hard to get rid of for example and highly addictive, they
> also cause some people to act like junkies-in-withdrawl when their
> binary driver breaks, or when someone suggests breaking it.
>
>

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Fri, 2005-12-16 at 16:28 -0500, Mike Snitzer wrote:
> Arjan,
> 
> I'm aware that RedHat has been shipping FC and RHEL kernels with 4K
> stacks for some time.  The recent 4K stack fixes pretty much establish
> that RedHat's early adoption of 4K stacks was a "cowbody development"
> no? 

(disclaimer: I don't work for Red Hat)

actually no. The only overflows seen in reality are with XFS, and Red
Hat doesn't support XFS anyway. The recent fix (not plural) was more a
precaution to let XFS work more reliable.


>  I don't think RedHat kept similar 4K stack fixes from upstream,
> so a bit of luck maybe?  I do agree that at this point the 4K-only
> proposal is NOT an overly rash decision given continued adequate
> vetting in -mm.  But even then there may be untested workloads that
> expose stack issues.  Which is perfectly fine if users have the option
> to use _supported_ alternate configs.

the problem to some degree is that those people if they hit this, won't
report it most likely. This is a problem because the same overflow can
hit with 8K stacks, just less frequent, so it really needs to be fixed
regardless of what anyone thinks of 4k-vs-8k stacks.


> I got the sense that you were trying to paint me as something of a
> closet "ndiswrapper addict".  

Actually I don't even know if you use ndiswrapper, but some others are
behaving like that; you're one of the "others" who actually try to use
real arguments.

> Amusing and all but my motivations for
> requesting continued options on the stack size are rooted in concerns
> that long call chains can and still do result when running kernel.org
> and RHEL4 kernels under particular workloads.  An example workload
> being cluster filesystems that in a single call chain historically
> _could_ leverage iptables + RPC (tcp) + DM (LVM) + etc.

funny you mention this one: iptables/RPC(tcp) actually run in the OTHER
4K stack; this workload has actually LESS chance of an overflow than
before... due to having more space in irq context.


> Given Neil Brown's fix for the block layer these stack-heavy workloads

which was pure preemptive and not based on actually observed problems
btw. it's a good fix nevertheless.

> All of us appreciate the desire to have Linux be more efficient and 4K
> stacks will get us that.  If it comes with the cost of instability
> under more exotic workloads then the bad outweighs the perceived good
> of imposed 4K stacks.  With RHEL4 it would seem we're past the point
> of no-return for supported 8K stacks.  I'm merely advocating upstream
> give users the 8K+IRQ stack _options_ and set the default to 4K.

note that I no longer care about this option going away or not; it's not
worth the silly flames (present company excluded ;)

options are good, to a degree. The extreme would be a kernel with 40.000
different config options, one for each patch that goes in. That's of
course silly! The other extreme is the gnome idea that preferences are
bad period. To a degree, Havoc and co are right in that there shouldn't
be a "unbreak my app" option, just like there shouldn't be a "unbreak my
kernel" config option. There needs to be some sort of reason and
proportion in all this. 

Where to draw the line is tricky I suppose and to a large degree a
matter of taste of the individual developer; but to be realistic; things
like 4-level pagetables or objrmap have a similar or higher risk of
breakage when they got in, and those didn't get config options
(something I agree with fwiw). In fact each 2.6.X release so far has had
2 or 3 major changes more risky/invasive than 4K stacks.

All that people say about 4k/4k stacks vs unified 8k stacks is
smoke-and-daggers to be honest (yes there were some problems in the past
with XFS, XFS got mostly fixed and Neil's patch fixes that for real, but
the basic things got fixed long ago). They forget that 2.4 got along
fine for a long time with a 4k/2k stack, or maybe chose to forget. All
those overflows you mention should hit double on 2.4 (and to be honest,
2.4 does hit some overflows, mostly due to the effective 2k irq side).
The 4k/4k approach is an extension on top of the 2.4 situation. 2.6 with
a unified 8k stack has a bit extra space, sure. but not dramatic much
more either. 

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Fri, Dec 16, 2005 at 04:28:15PM -0500, Mike Snitzer wrote:
>...
> Given Neil Brown's fix for the block layer these stack-heavy workloads
> that included DM in the call chain need to be revisited.  However, the
> savings associated with those particular fixes still may not leave
> sufficient breathing room.  The logic that all users must NOW provide
> workloads which undermine 4K stack viability otherwise the 8K option
> will be completely removed _seems_ quite irrational (even though we
> are _supposedly_ just talking about doing so in -mm).
> 
> All of us appreciate the desire to have Linux be more efficient and 4K
> stacks will get us that.  If it comes with the cost of instability
> under more exotic workloads then the bad outweighs the perceived good
> of imposed 4K stacks.  With RHEL4 it would seem we're past the point
> of no-return for supported 8K stacks.  I'm merely advocating upstream
> give users the 8K+IRQ stack _options_ and set the default to 4K.

My count of bug reports for problems with in-kernel code with 4k stacks 
after Neil's patch went into -mm is still at 0. That's amazing 
considering how many people have claimed in this thread how unstable
4k stacks were...

Enabling 4k stacks unconditionally for all -mm users will give us a 
wider testing coverage and will tell us whether we have really fixed all 
bugs that become visible with 4k stacks or whether there are still bugs 
left.

-mm kernels contain many experimental features, and "completely removed" 
isn't really true because we can expect that people running the 
experimental -mm kernels to know how to un-apply a patch.

> Mike

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] i386: always use 4k stacks

[Dave Jones]

On Fri, Dec 16, 2005 at 10:50:54PM +0100, Adrian Bunk wrote:
 > On Fri, Dec 16, 2005 at 04:28:15PM -0500, Mike Snitzer wrote:
 > >...
 > > Given Neil Brown's fix for the block layer these stack-heavy workloads
 > > that included DM in the call chain need to be revisited.  However, the
 > > savings associated with those particular fixes still may not leave
 > > sufficient breathing room.  The logic that all users must NOW provide
 > > workloads which undermine 4K stack viability otherwise the 8K option
 > > will be completely removed _seems_ quite irrational (even though we
 > > are _supposedly_ just talking about doing so in -mm).
 > > 
 > > All of us appreciate the desire to have Linux be more efficient and 4K
 > > stacks will get us that.  If it comes with the cost of instability
 > > under more exotic workloads then the bad outweighs the perceived good
 > > of imposed 4K stacks.  With RHEL4 it would seem we're past the point
 > > of no-return for supported 8K stacks.  I'm merely advocating upstream
 > > give users the 8K+IRQ stack _options_ and set the default to 4K.
 > 
 > My count of bug reports for problems with in-kernel code with 4k stacks 
 > after Neil's patch went into -mm is still at 0. That's amazing 
 > considering how many people have claimed in this thread how unstable
 > 4k stacks were...
 > 
 > Enabling 4k stacks unconditionally for all -mm users will give us a 
 > wider testing coverage and will tell us whether we have really fixed all 
 > bugs that become visible with 4k stacks or whether there are still bugs 
 > left.

As another anecdotal point, the number of oomkill/page alloc failure
related bugs that get filed against Fedora these days you can count
on one hand.  Before we switched over to 4K stacks, we were
getting regular reports from users having quite sane workloads on
capable machines getting jobs killed left and right.

Now the only cases we're seeing is usually loonies trying to
put silly amounts of RAM in 32bit systems, and the occasional
bug which turns out to be a slab leak or something similar.
(There's one oddball right now where someone sees his 5GB
 x86-64 run out of DMA zone, but that might 'go away' when
 we push out a kernel with the DMA32 zone).

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> On Dec 16, 2005, at 10:35, Diego Calleja wrote:
> > I know, but there's too much resistance to the "pure" 4kb patch.
> 
> I have yet to see any resistance to the 4Kb patch this time around
> that was not "*whine* don't break my ndiswrapper plz".  

My comment from last time about the missing safety net still applies 100%.

Kernel code is getting more complex all the time and running with
very tight stack is just risky.

> The point is to force it in -mm so most people can't just disable it
> because it fixes their problem.  We want 8k stacks to go away, and

Who is we? And why? 

About the only half way credible arguments I've seen for it were:  

- "it might reduce stalls in the VM with order 1". Didn't quite
convince me because there were no numbers presented and at least on
x86-64 I've never noticed or got reported significant stalls because
of this.

- "it allows more threads for 32bit which might run out of lowmem" - i
think everybody agrees that the 10k threads case is not really
something to encourage. And even when you want to add it then only a factor
two increase (which this patch brings) is not really too helpful.

The main argument thrown around seems to be "but it will break
binary only modules" - while I'm not fully unsympathetic I don't
think technical issues in the kernel should be guided by 
such political considerations.

I suspect you will be reposting it so often till the voices
of reasons get tired? 

-Andi

Re: [2.6 patch] i386: always use 4k stacks

[Kyle Moffett]

On Dec 17, 2005, at 12:44, Andi Kleen wrote:
> Kernel code is getting more complex all the time and running with  
> very tight stack is just risky.

IMPORTANT POINT:  The 4k-stacks code does *NOT* reduce overall  
available stack!!!  With the old code we have 8k of _total_ stack.   
With the new code we have 4k of interrupt stack and 4k of per-process  
stack.  This makes stack-overflows a _LOT_ more debuggable, because  
it's not a coincidence of high process-stack-usage and high interrupt- 
stack-usage.

>> The point is to force it in -mm so most people can't just disable  
>> it  because it fixes their problem.  We want 8k stacks to go away
>
> Who is we? And why?
>
> About the only half way credible arguments I've seen for it were:

I posted a list of links to the archives of various reasons a day or  
so ago, but for summary:

This helps for some NUMA systems because single pages can come out of  
a per-cpu pool instead of requiring global allocator locks.

> - "it might reduce stalls in the VM with order 1". Didn't quite  
> convince me because there were no numbers presented and at least on  
> x86-64 I've never noticed or got reported significant stalls  
> because of this.

One comment on x86-64 vs. x86:  There are restrictions on where in  
memory your process stacks can be located on a 32-bit platform.  They  
need to reside in lowmem, which means under certain circumstances  
your lowmem can get too fragmented to create new processes even  
though you still have a lot of available RAM.

> - "it allows more threads for 32bit which might run out of lowmem"  
> - i think everybody agrees that the 10k threads case is not really  
> something to encourage.

Who is this "everybody" of whom you speak?  :-D.  Personally I agree  
that we shouldn't _encourage_ 10k threads, but there are existing  
userspace programs which do that, and I think we should support them  
as much as possible.

> And even when you want to add it then only a factor two increase  
> (which this patch brings) is not really too helpful.

The fragmentation behavior and optimizations for order-1 vs. order-0  
_is_ significant.  You can _always_ allocate order-0 pages if you  
have any free memory in that zone, which is _not_ necessarily true  
for order-N pages. (even if N==1).  Also, I think some of the  
fragmentation avoidance attempts get significantly easier and produce  
much better results if all the kernel stacks are order-0.

Cheers,
Kyle Moffett

--
If you don't believe that a case based on [nothing] could potentially  
drag on in court for _years_, then you have no business playing with  
the legal system at all.
   -- Rob Landley

Re: [2.6 patch] i386: always use 4k stacks

[Paul Rolland]

Hello,

> One comment on x86-64 vs. x86:  There are restrictions on where in  
> memory your process stacks can be located on a 32-bit 
> platform.  They  
> need to reside in lowmem, which means under certain circumstances  
> your lowmem can get too fragmented to create new processes even  
> though you still have a lot of available RAM.

But where does these restrictions come from ? As far as I know, stack
is referenced to by SS:ESP registers, and nothing in the x86 architecture
prevents them from pointing outside of lowmem... Isn't this simply a
Linux design restriction ?

Regards,
Paul


Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it" 

"I worry about my child and the Internet all the time, even though she's 
too young to have logged on yet. Here's what I worry about. I worry that 
10 or 15 years from now, she will come to me and say 'Daddy, where were 
you when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Sat, 2005-12-17 at 21:23 +0100, Paul Rolland wrote:
> Hello,
> 
> > One comment on x86-64 vs. x86:  There are restrictions on where in  
> > memory your process stacks can be located on a 32-bit 
> > platform.  They  
> > need to reside in lowmem, which means under certain circumstances  
> > your lowmem can get too fragmented to create new processes even  
> > though you still have a lot of available RAM.
> 
> But where does these restrictions come from ? As far as I know, stack
> is referenced to by SS:ESP registers, and nothing in the x86 architecture
> prevents them from pointing outside of lowmem... Isn't this simply a
> Linux design restriction ?

lowmem is a linux design restriction; only lowmem is directly
addressable.

(also remember that you can have 36 bits of physical ram, but only 32
bit in a pointer, so even if lowmem wasn't 870Mb itd be limited to 4Gb)

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sat, Dec 17, 2005 at 06:44:07PM +0100, Andi Kleen wrote:
> Kyle Moffett <mrmacman_g4@mac.com> writes:
> 
> > On Dec 16, 2005, at 10:35, Diego Calleja wrote:
> > > I know, but there's too much resistance to the "pure" 4kb patch.
> > 
> > I have yet to see any resistance to the 4Kb patch this time around
> > that was not "*whine* don't break my ndiswrapper plz".  
> 
> My comment from last time about the missing safety net still applies 100%.
> 
> Kernel code is getting more complex all the time and running with
> very tight stack is just risky.

My patch reduces it from roughly 6kB to 4kB.

I'm with you that we need a safety net, but I don't see a problem with 
this being between 3kB and 4kB. The goal should be to _never_ use more 
than 3kB stack having a 1kB safety net.

And in my experience, many stack problems don't come from code getting 
more complex but from people allocating 1kB structs or arrays of
> 2k chars on the stack. In these cases, the code has to be fixed and 
"make checkstack" makes it easy to find such cases.

And as a data point, my count of bug reports for problems with in-kernel 
code with 4k stacks after Neil's patch went into -mm is still at 0.

> > The point is to force it in -mm so most people can't just disable it
> > because it fixes their problem.  We want 8k stacks to go away, and
> 
> Who is we? And why? 
> 
> About the only half way credible arguments I've seen for it were:  
> 
> - "it might reduce stalls in the VM with order 1". Didn't quite
> convince me because there were no numbers presented and at least on
> x86-64 I've never noticed or got reported significant stalls because
> of this.
> 
> - "it allows more threads for 32bit which might run out of lowmem" - i
> think everybody agrees that the 10k threads case is not really
> something to encourage. And even when you want to add it then only a factor
> two increase (which this patch brings) is not really too helpful.
>...

Unfortunately, "is not really something to encourage" doesn'a make 
"happens in real-life applications" impossible...

Reducing the stack by one third brings a factor two reduction in the 
memory usage of threads - I wouldn't say this sounds too bad.

> -Andi

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] i386: always use 4k stacks

[Andi Kleen]

> > - "it allows more threads for 32bit which might run out of lowmem" - i
> > think everybody agrees that the 10k threads case is not really
> > something to encourage. And even when you want to add it then only a factor
> > two increase (which this patch brings) is not really too helpful.
> >...
> 
> Unfortunately, "is not really something to encourage" doesn'a make 
> "happens in real-life applications" impossible...

real-life applications can either use user space threads or 64bit
machines. The days when Linux did otherwise unjustificable ha^w^wdesign 
changes just to work around the 900MB lowmem on weird loads on 
extremly big 32bit machines are pretty much over I think... 

-Andi

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Dec 17, 2005, at 3:52 PM, Adrian Bunk wrote:

> And in my experience, many stack problems don't come from code getting
> more complex but from people allocating 1kB structs or arrays of

And we catch this type of problems fairly easily in the patch review  
itself, even before accepting the code in mainline. Plus there is  
make checkstack to help find and fix any such issues, isn't it? So  
it's not like forcing the stack to 4Kb and making the offending code  
to crash is the best solution to force people to write code which  
plays nice with the stack.

I think on i386 most people do fine with the 8Kb stack - whoever  
benefits from 4Kb stack, can always choose the 4Kb stack config  
option and recompile.

Alternatively, default to 4Kb and let people choose 8Kb and recompile  
if that's what suits their workloads.

In any case having options doesn't hurt anything and we don't benefit  
in any way from taking away the 8Kb option.

My 2 cents.

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

On Sun, Dec 18, 2005 at 12:03:39AM -0500, Parag Warudkar wrote:
> 
> On Dec 17, 2005, at 3:52 PM, Adrian Bunk wrote:
> 
> >And in my experience, many stack problems don't come from code getting
> >more complex but from people allocating 1kB structs or arrays of
> 
> And we catch this type of problems fairly easily in the patch review  
> itself, even before accepting the code in mainline. Plus there is  

You can catch the obvious ones, but the really hard ones
that only occur under high load in obscure exceptional
circumstances with large configurations and suitable nesting you won't. 
These would be only found at real world users.

-Andi

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Dec 18, 2005, at 12:43 AM, Andi Kleen wrote:

> You can catch the obvious ones, but the really hard ones
> that only occur under high load in obscure exceptional
> circumstances with large configurations and suitable nesting you  
> won't.
> These would be only found at real world users.

Yep, as it all depends on code complexity, some of these cases might  
not be "errors" at all - instead for that kind of functionality they  
might _require_ bigger stacks.

If you have 64 bit machines common place and memory a lot cheaper I  
don't see how it is beneficial to force smaller stack sizes without  
giving consideration to the code complexity, architecture and  
requirements.
(Solaris for example, seems to be going to have 16Kb kernel stacks on  
64 bit machines.)

So, please let's leave stack size as an option for users to choose  
and stop this 4Kb stack war. May be after a little rest I will start  
another one demanding 16Kb stacks :)

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 01:05:52AM -0500, Parag Warudkar wrote:
> 
> On Dec 18, 2005, at 12:43 AM, Andi Kleen wrote:
> 
> >You can catch the obvious ones, but the really hard ones
> >that only occur under high load in obscure exceptional
> >circumstances with large configurations and suitable nesting you  
> >won't.
> >These would be only found at real world users.
> 
> Yep, as it all depends on code complexity, some of these cases might  
> not be "errors" at all - instead for that kind of functionality they  
> might _require_ bigger stacks.

Is this just FUD or can you give an example where this is a real 
problem that can't be solved by using kmalloc()?

> If you have 64 bit machines common place and memory a lot cheaper I  
> don't see how it is beneficial to force smaller stack sizes without  
> giving consideration to the code complexity, architecture and  
> requirements.
>...

Note that we are talking about reducing the stack size _by one third_.

Therefore, your point it would make code much more complex sounds 
strange.

> Parag

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] i386: always use 4k stacks

[Parag Warudkar]

On Dec 18, 2005, at 10:51 AM, Adrian Bunk wrote:

> Is this just FUD or can you give an example where this is a real
> problem that can't be solved by using kmalloc()?

Can you prove "Under all uses, circumstances and code requirements we  
will do fine with 4K stacks today and tomorrow" ? How will deeply  
nested function calls, longer call chains etc. be solved by kmalloc()?

> Therefore, your point it would make code much more complex sounds
> strange.

My point wasn't that reducing stack will make code much more complex.  
My point was some type of functionality might validly require complex  
code which requires more stack - there are capable and affordable  
machines to solve such problems and all we are doing with 4kB stacks  
is that preventing it.

Again - what is the pressing need to remove the "8Kb Stack _Option_"?  
What problem does it solve on 64 bit arches?

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

Parag Warudkar wrote:

>
> On Dec 18, 2005, at 12:43 AM, Andi Kleen wrote:
>
>> You can catch the obvious ones, but the really hard ones
>> that only occur under high load in obscure exceptional
>> circumstances with large configurations and suitable nesting you  won't.
>> These would be only found at real world users.
>
>
> Yep, as it all depends on code complexity, some of these cases might  
> not be "errors" at all - instead for that kind of functionality they  
> might _require_ bigger stacks.
>
No complex problem ever requires a big stack.  It may require a large amount
of memory - which can be allocated explicitly outside the stack.

> If you have 64 bit machines common place and memory a lot cheaper I  
> don't see how it is beneficial to force smaller stack sizes without  
> giving consideration to the code complexity, architecture and  
> requirements.
> (Solaris for example, seems to be going to have 16Kb kernel stacks on  
> 64 bit machines.)
>
> So, please let's leave stack size as an option for users to choose  
> and stop this 4Kb stack war. May be after a little rest I will start  
> another one demanding 16Kb stacks :)

I suggest a little experiment for you.  Make a kernel module which do 
nothing
except try to allocate 16k of _contigous_ kernel memory, and
printk whether it succeeded or failed before exiting.  Have cron run that
every 5 minutes.  After a few weeks of running this low-impact test on
a busy loaded server, look at statistics about how often the 16k allocation
worked - and how often it failed. 

Whatever failure rate you get, expect the same failure rate for server
processes forking to handle new connections while running with 16k stacks.
Failing one out of a hundred times would probably not be tolerated
for a webserver, and I suspect the failure rate for this will be higher - if
the machine has a reasonable memory load and the usual fragmentation.

On the other hand, if you can surprise us about how this works very
well - then you have a strong argument!

Helge Hafting

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Dec 19, 2005, at 6:09 AM, Helge Hafting wrote:

> I suggest a little experiment for you.  Make a kernel module which  
> do nothing
> except try to allocate 16k of _contigous_ kernel memory, and
> printk whether it succeeded or failed before exiting.  Have cron  
> run that
> every 5 minutes.  After a few weeks of running this low-impact test on
> a busy loaded server, look at statistics about how often the 16k  
> allocation
> worked - and how often it failed.

I am aware of the limitations of Linux MM and the problems associated  
with anything more than zero order allocations over a period of time.

My argument was it's not that a ton of i386 users are affected by  
having choice of stack sizes (I read LKML quite frequently and for  
long I don't remember seeing allocation failure errors - either  
people moved to 64  bits without LOWMEM and that helped or people  
just do fine with the current 8K stack on i386) and even if some are,  
let's leave the stack size as an option - it's not like it cause a  
lot of code bloat or other problems (I read your argument about VM  
developers bogged down by having to deal with 8K stacks but quite  
frankly I don't understand how.)

Whoever benefits can use the 4K stacks, others who feel it risky to  
have 4K stacks for whatever reason, can be happy too. We can even  
make the 4K default, but having supported option of 8K is important  
and almost all operating systems are having >4K stacks on i386  
machines, so there is some reason for having it.

But I rest my argument, I no longer use i386 and I am being told this  
patch only affects i386! ;)

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Dumitru Ciobarcianu]

În data de Lu, 19-12-2005 la 11:22 -0500, Parag Warudkar a scris:
> Whoever benefits can use the 4K stacks, others who feel it risky to  
> have 4K stacks for whatever reason, can be happy too. We can even  
> make the 4K default, but having supported option of 8K is important  
> and almost all operating systems are having >4K stacks on i386  
> machines, so there is some reason for having it.

Sloppy coding ? As long you don't have the source you can't be sure.
Point to an open source (and not tainting by just reading it) code which
uses >4k+IRQstack stacks.

Millions of flyes eat shit.
It must be a reason for having it...

-- 
Cioby

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Dec 19, 2005, at 12:43 PM, Dumitru Ciobarcianu wrote:

> Sloppy coding ? As long you don't have the source you can't be sure.
> Point to an open source (and not tainting by just reading it) code  
> which
> uses >4k+IRQstack stacks.
>

First you gotta understand that I am not arguing to take away the 4K  
stacks - I am arguing about keeping both options and defaulting to 4K.

How do you determine how much stack space a piece of code is going to  
need without knowing what functionality it needs to build? There  
might be deeply nested, long call chains etc. which certain types of  
functionality might warrant. How do you prove "4K otta be enough  
stack for everyone doing everything", on what basis? (Reminds me of  
old DOS days and the famous statement relating to 640K)

> Millions of flyes eat shit.
> It must be a reason for having it...
>

Yeah, compare that same thing to FORCING 4K stacks - it sounds as  
illogical as the above statement.

No one is answering what are we gaining from removing the 8K stack  
"_option_" - few bytes of code size, reason to not fix the VM, for  
fun, for screwing over? Why not let people choose 8K if they need it?

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Dumitru Ciobarcianu]

În data de Lu, 19-12-2005 la 14:10 -0500, Parag Warudkar a scris:
> On Dec 19, 2005, at 12:43 PM, Dumitru Ciobarcianu wrote:
> 
> > Sloppy coding ? As long you don't have the source you can't be sure.
> > Point to an open source (and not tainting by just reading it) code  
> > which
> > uses >4k+IRQstack stacks.
> >
> 
> First you gotta understand that I am not arguing to take away the 4K  
> stacks - I am arguing about keeping both options and defaulting to 4K.

Yes, and I agree with you on that, but you din't answered my question
regarding _which_ os you mentioned needing more stack space and why.

-- 
Cioby

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Dec 19, 2005, at 2:27 PM, Dumitru Ciobarcianu wrote:

> but you din't answered my question
> regarding _which_ os you mentioned needing more stack space and why.

The two other commercially successful OSes - Windows and Solaris have  
12Kb and 8Kb default kernel stack sizes. And both seem to do well  
(hold on :) with the large stack sizes - meaning there is no  
commercially observed problem created by the 8K stack size. Solaris  
even lets you change the kernel stack size at runtime.

Even if we keep aside the impending argument about both OS'es being  
crap and we shouldn't be imitating them, we could still derive one  
conclusion from them - it is possible to have larger stack on i386  
without problems (albeit with some drawbacks) which could be used  
under certain circumstances.

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Dumitru Ciobarcianu]

În data de Lu, 19-12-2005 la 15:17 -0500, Parag Warudkar a scris:
> On Dec 19, 2005, at 2:27 PM, Dumitru Ciobarcianu wrote:
> 
> > but you din't answered my question
> > regarding _which_ os you mentioned needing more stack space and why.
> 
> The two other commercially successful OSes - Windows and Solaris have  
> 12Kb and 8Kb default kernel stack sizes. And both seem to do well  
> (hold on :) with the large stack sizes - meaning there is no  
> commercially observed problem created by the 8K stack size. Solaris  
> even lets you change the kernel stack size at runtime.

My point was that you don't know why those two OS have such a large
stack. Just because you can't look at the source without being
contaminated.


-- 
Cioby - "I'll just stop feeding the troll now"

Re: [2.6 patch] i386: always use 4k stacks

[Tue, 20 Dec 2005 02:24:16 +0100]

El Mon, 19 Dec 2005 22:34:57 +0200,
Dumitru Ciobarcianu <Dumitru.Ciobarcianu@iNES.RO> escribió:

> My point was that you don't know why those two OS have such a large
> stack. Just because you can't look at the source without being
> contaminated.

opensolaris is open source, you can look at their code.

But I don't think you'll find an answer there. My bet is: because
it'd be more difficult for their customers (even if opensolaris
is opensource it was born as propietary OS), because doing it
doesn't buys you performance and customers, there're not
lot of reasons for doing it, etc.

As I understand it, linux is "different". I'd say that the main
"philosophic" (not technical) reason for going 4K is: "because
we have the balls to write a 4k-stack-safe kernel". Quoting Linus:

"I hold open source people to higher standards. They are supposed to be
 the people who do programming because it's an art-form, not because it's
 their job."

Re: [2.6 patch] i386: always use 4k stacks

[Horst von Brand]

Parag Warudkar <kernel-stuff@comcast.net> wrote:
> On Dec 19, 2005, at 2:27 PM, Dumitru Ciobarcianu wrote:
> > but you din't answered my question
> > regarding _which_ os you mentioned needing more stack space and why.

> The two other commercially successful OSes - Windows and Solaris have
> 12Kb and 8Kb default kernel stack sizes. And both seem to do well
> (hold on :) with the large stack sizes - meaning there is no
> commercially observed problem created by the 8K stack size. Solaris
> even lets you change the kernel stack size at runtime.

> Even if we keep aside the impending argument about both OS'es being
> crap 

Right.

>      and we shouldn't be imitating them,

Nodz. That doesn't mean they don't have their strong points, which we
should consider carefully.

>                                          we could still derive one
> conclusion from them - it is possible to have larger stack on i386
> without problems (albeit with some drawbacks) which could be used
> under certain circumstances.

"With some drawbacks" is the point: It has been determined that the
drawbacks are heavy enough that the 8KiB stack option should go. Given
there is /no/ compelling argument /against/ 4KiB stacks, even very minor
drawbacks are important. So first make 4KiB the standard (popular
distributions work that way for /years/ now, with no measurable downsides),
then axe 8KiB stack as an option. Also note that 8KiB stacks really only
gives 4KiB to the process (plus (or minus!) a random ammount depending on
the interrupts being serviced ATM), and this has been so forever.

Oh, well, one of the larger drawbacks of 4KiB stacks is the inevitable
flamewar, each time with /less/ data (this round I've seen none) supporting
the need for larger stacks, into which all kinds of idiots* are suckered.

* This certainly includes myself
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [2.6 patch] i386: always use 4k stacks

[David Lang]

On Tue, 20 Dec 2005, Horst von Brand wrote:

>
> "With some drawbacks" is the point: It has been determined that the
> drawbacks are heavy enough that the 8KiB stack option should go. Given
> there is /no/ compelling argument /against/ 4KiB stacks, even very minor
> drawbacks are important. So first make 4KiB the standard (popular
> distributions work that way for /years/ now, with no measurable downsides),

at least one of the 'popular distributions' that switched to 4k stacks 
years ago worked around the problems that it generated by simply lableing 
the portions that didn't work with 4k stacks as 'unsupported by this 
distro' (XFS has been explicitly stated to be in this catagory in these 
discussions)

how many other corner cases are there that these distros just choose not 
to support, but need to be supported and tested for the vanilla kernel?

also for those who are arguing that it's only dropping from 6k to 4k, you 
are forgetting that the patches to move the interrupts to a seperate stack 
have already gone into the kernel, so today it is really 8k+4k and the 
talk is to move it to 4k+4k.

I think it's a good idea to change the default (especially in -mm) to 4k 
stacks and to schedule a change of the default in mainline for a few 
versions out, but there needs to be a safety net other then telling people 
to downgrade to a prior kernel if they run into problems when the switch 
is made

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> 
> how many other corner cases are there that these distros just choose not 
> to support, but need to be supported and tested for the vanilla kernel?

as someone who was at that distro in the time.. none other than XFS and
reiserfs4.

> also for those who are arguing that it's only dropping from 6k to 4k, you 
> are forgetting that the patches to move the interrupts to a seperate stack 
> have already gone into the kernel, so today it is really 8k+4k and the 
> talk is to move it to 4k+4k.

actually irq stacks aren't enabled with 8K stacks right now, so your
statement isn't correct.

Re: [2.6 patch] i386: always use 4k stacks

[David Lang]

On Tue, 20 Dec 2005, Arjan van de Ven wrote:

>> how many other corner cases are there that these distros just choose not
>> to support, but need to be supported and tested for the vanilla kernel?
>
> as someone who was at that distro in the time.. none other than XFS and
> reiserfs4.

good to hear, outsiders don't know these details. all we know is that some 
things aren't supported, but (without a lot of effort) don't know what 
things.

>> also for those who are arguing that it's only dropping from 6k to 4k, you
>> are forgetting that the patches to move the interrupts to a seperate stack
>> have already gone into the kernel, so today it is really 8k+4k and the
>> talk is to move it to 4k+4k.
>
> actually irq stacks aren't enabled with 8K stacks right now, so your
> statement isn't correct.

Ok, I stand corrected, I didn't look at the code, I was going on the 
memories of the discussions on l-k where the advocates were pushing to 
enable the interrupt stacks unconditionally, and I was remembering that a 
patch to do so had gone in.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [2.6 patch] i386: always use 4k stacks

[Sander]

Arjan van de Ven wrote (ao):
> > how many other corner cases are there that these distros just choose
> > not to support, but need to be supported and tested for the vanilla
> > kernel?
> 
> as someone who was at that distro in the time.. none other than XFS
> and reiserfs4.

FWIW, I have a few servers and my workstation running Reiser4 and
CONFIG_4KSTACKS=y for several months now, and haven't encountered
problems yet. One server also runs Reiser4 on top op lvm2, and another
Reiser4 on top of sw raid1.

I know -mm + Reiser4 + 4kstacks is bleeding edge in more than one way,
but I like that for my workstations and the servers are
test/non-critical.

All systems do have real-life load though. I'd be happy to provide data
from these systems. Just mail me the commands.

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: [2.6 patch] i386: always use 4k stacks

[Jeffrey Hundstad]

Sander wrote:

>Arjan van de Ven wrote (ao):
>  
>
>>>how many other corner cases are there that these distros just choose
>>>not to support, but need to be supported and tested for the vanilla
>>>kernel?
>>>      
>>>
>>as someone who was at that distro in the time.. none other than XFS
>>and reiserfs4.
>>    
>>
>
>FWIW, I have a few servers and my workstation running Reiser4 and
>CONFIG_4KSTACKS=y for several months now, and haven't encountered
>problems yet. One server also runs Reiser4 on top op lvm2, and another
>Reiser4 on top of sw raid1.
>
>I know -mm + Reiser4 + 4kstacks is bleeding edge in more than one way,
>but I like that for my workstations and the servers are
>test/non-critical.
>
>All systems do have real-life load though. I'd be happy to provide data
>from these systems. Just mail me the commands.
>
>  
>

I would like to add to this.  I've been using XFS+LVM+SCSI in a 14,000+ 
user University email server with 4k stacks since it became available.  
I didn't even have problems BEFORE the XFS stuff was stack-dieted.  I 
would also be happy to provide more data.

-- 
Jeffrey Hundstad

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Tue, Dec 20, 2005 at 09:56:10AM -0800, David Lang wrote:
> On Tue, 20 Dec 2005, Horst von Brand wrote:
> 
> >
> >"With some drawbacks" is the point: It has been determined that the
> >drawbacks are heavy enough that the 8KiB stack option should go. Given
> >there is /no/ compelling argument /against/ 4KiB stacks, even very minor
> >drawbacks are important. So first make 4KiB the standard (popular
> >distributions work that way for /years/ now, with no measurable downsides),
> 
> at least one of the 'popular distributions' that switched to 4k stacks 
> years ago worked around the problems that it generated by simply lableing 
> the portions that didn't work with 4k stacks as 'unsupported by this 
> distro' (XFS has been explicitly stated to be in this catagory in these 
> discussions)

AFAIK, XFS is the only example.
And the XFS related problems have already been fixed.

> how many other corner cases are there that these distros just choose not 
> to support, but need to be supported and tested for the vanilla kernel?

My count of bug reports for problems with in-kernel code with 4k stacks 
after Neil's patch went into -mm is still at 0.

If 4k stacks were as unstable as you imply, why has noone been able to 
point to _one single_ problem with 4k stacks that is still present 
after Neil's patch went into -mm?

> also for those who are arguing that it's only dropping from 6k to 4k, you 
> are forgetting that the patches to move the interrupts to a seperate stack 
> have already gone into the kernel, so today it is really 8k+4k and the 
> talk is to move it to 4k+4k.
>...

That's complete bullshit.

Currently, seperate irq stacks are only used with 
CONFIG_4KSTACKS=y.

> David Lang

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] i386: always use 4k stacks

[Sean]

On Tue, December 20, 2005 12:56 pm, David Lang said:
>
> at least one of the 'popular distributions' that switched to 4k stacks
> years ago worked around the problems that it generated by simply lableing
> the portions that didn't work with 4k stacks as 'unsupported by this
> distro' (XFS has been explicitly stated to be in this catagory in these
> discussions)

Times change, the XFS issues have been resolved.

> how many other corner cases are there that these distros just choose not
> to support, but need to be supported and tested for the vanilla kernel?

This is called FUD.  If you have examples of a problem go ahead and post
them.   *EVERY* change made to the kernel has the potential to cause a
problem.   But this one has been carefully scrutinized and it seems that
only people with general notions of FUD remain to object.   Nobody seems
to have any real objections any more.  YAY!

> also for those who are arguing that it's only dropping from 6k to 4k, you
> are forgetting that the patches to move the interrupts to a seperate stack
> have already gone into the kernel, so today it is really 8k+4k and the
> talk is to move it to 4k+4k.

So what?   The point is that if you compare the world from what it was a
few years back with just 8K, now there is just as much stack space,
although it happens to be split in half.

> I think it's a good idea to change the default (especially in -mm) to 4k
> stacks and to schedule a change of the default in mainline for a few
> versions out, but there needs to be a safety net other then telling people
> to downgrade to a prior kernel if they run into problems when the switch
> is made

Of course.   If there are problems discovered in -mm with 4K stack (highly
unlikely since its been in production use on several vendor kernals for a
few years) they will be dealt with.   But once a reasonable period of time
has passed with no issues, its time to move it into mainline.

Sean

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Tue, Dec 20, 2005 at 09:56:10AM -0800, David Lang wrote:

 > at least one of the 'popular distributions' that switched to 4k stacks 
 > years ago worked around the problems that it generated by simply lableing 
 > the portions that didn't work with 4k stacks as 'unsupported by this 
 > distro' (XFS has been explicitly stated to be in this catagory in these 
 > discussions)

Actually there are several reasons why certain parts are
unsupported in RHEL kernels.  The fact that XFS blew up with
4k stacks was purely coincidental to it being unsupported.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Mon, Dec 19, 2005 at 02:10:17PM -0500, Parag Warudkar wrote:
>...
> How do you determine how much stack space a piece of code is going to  
> need without knowing what functionality it needs to build? There  
> might be deeply nested, long call chains etc. which certain types of  
> functionality might warrant.

Static analysis of this problem is possible.

"make checkstack" is a good starting point.

And the automatic analysis of all possible call chains can and has 
already found problems.

> How do you prove "4K otta be enough  
> stack for everyone doing everything", on what basis? (Reminds me of  
> old DOS days and the famous statement relating to 640K)
>...

We are talking about reducing the stack size by one third which doesn't 
result in a fundamental difference.

There is no technical reason why 4 kB shouldn't be enough - I don't 
count sloppy coding as a reason for it since in such cases we better 
correct the code.

> Parag

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] i386: always use 4k stacks

[Felix Oxley]

On 19 Dec 2005, at 19:10, Parag Warudkar wrote:

>
> No one is answering what are we gaining from removing the 8K stack  
> "_option_" - few bytes of code size, reason to not fix the VM, for  
> fun, for screwing over? Why not let people choose 8K if they need it?

The proposed patch is for mm only. What you are gaining is wider  
testing of 4K stacks.

I am just a lurker but, having read the entire thread, it seems to me  
that:
1) the patch should be applied to mm.
2) ndiswrapper should be modified to work with 4K stacks.

It seems unlikely to me that this patch will be pushed to Linus just  
because it has been in mm.
If that possibility comes up in 6-12 months then the flamewar can  
begin again.

regards,
Felix
  

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 06:43:23AM +0100, Andi Kleen wrote:
> On Sun, Dec 18, 2005 at 12:03:39AM -0500, Parag Warudkar wrote:
> > 
> > On Dec 17, 2005, at 3:52 PM, Adrian Bunk wrote:
> > 
> > >And in my experience, many stack problems don't come from code getting
> > >more complex but from people allocating 1kB structs or arrays of
> > 
> > And we catch this type of problems fairly easily in the patch review  
> > itself, even before accepting the code in mainline. Plus there is  
> 
> You can catch the obvious ones, but the really hard ones
> that only occur under high load in obscure exceptional
> circumstances with large configurations and suitable nesting you won't. 
> These would be only found at real world users.

You miss the fact that many of these problems can be detected by static 
analysis.

We know that we don't have any non-recursive paths with > 3 kB stack 
usage anymore since the beginning of this year, and the known recursive 
problems should be attacked by Neil's patch.

> -Andi

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] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 12:03:39AM -0500, Parag Warudkar wrote:
> 
> On Dec 17, 2005, at 3:52 PM, Adrian Bunk wrote:
> 
> >And in my experience, many stack problems don't come from code getting
> >more complex but from people allocating 1kB structs or arrays of
> 
> And we catch this type of problems fairly easily in the patch review  
> itself, even before accepting the code in mainline. Plus there is  
> make checkstack to help find and fix any such issues, isn't it? So  
> it's not like forcing the stack to 4Kb and making the offending code  
> to crash is the best solution to force people to write code which  
> plays nice with the stack.

4kB stacks are already an option for some time. There were some problems 
in the beginning, but as far as we know we have have fixed all of them.

There are so many possible bugs people writing kernel code could 
introduce bugs that cause crashes. The solution is not to add 
workarounds for programming bugs at every possible place, but as the
code review and "make checkstack" before accepting code.

As a data point, my count of bug reports for problems with in-kernel 
code with 4k stacks after Neil's patch went into -mm is still at 0.

> I think on i386 most people do fine with the 8Kb stack - whoever  
> benefits from 4Kb stack, can always choose the 4Kb stack config  
> option and recompile.
> 
> Alternatively, default to 4Kb and let people choose 8Kb and recompile  
> if that's what suits their workloads.
>...

There is no workload where 8kB suits better.

> My 2 cents.
> 
> Parag

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] i386: always use 4k stacks

[Parag Warudkar]

On Dec 18, 2005, at 7:09 AM, Adrian Bunk wrote:

> There is no workload where 8kB suits better.

People have pointed out that there is currently at least one  
incompatibility introduced by 4K stacks and there may be many others  
which are corner cases, that only occur under high load in obscure  
exceptional circumstances with large configurations and suitable  
nesting.

Moreover for 64 bit architectures there is no proven point that 4Kb  
stacks are solving a specific problem there (Like the lowmem  
fragmentation on i386 for e.g.). Nor can we predict for sure that in  
future no type of functionality will require more stack. So taking  
away 8Kb stack size on such arches solves no known problems and  
introduces artificial limitations on code complexity.

All I am asking is what is wrong with having options? You can even  
default to 4Kb and let people choose 8Kb when they absolutely benefit  
from it. Does having options introduce code bloat or what is it that  
is pressing so hard to remove the 8Kb "option"?

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Sun, Dec 18, 2005 at 10:49:31AM -0500, Parag Warudkar wrote:
> 
> On Dec 18, 2005, at 7:09 AM, Adrian Bunk wrote:
> 
> >There is no workload where 8kB suits better.
> 
> People have pointed out that there is currently at least one  
> incompatibility introduced by 4K stacks and there may be many others  

That's wrong.

My count of bug reports for problems with 4k stacks with in-kernel code 
after Neil's patch went into -mm is still at 0.

> which are corner cases, that only occur under high load in obscure  
> exceptional circumstances with large configurations and suitable  
> nesting.

And this is not that much of an issue since most of these cases can and 
have already been analyzed by static analysis to be below 3 kB stack 
usage.

> Moreover for 64 bit architectures there is no proven point that 4Kb  
> stacks are solving a specific problem there (Like the lowmem  
> fragmentation on i386 for e.g.). Nor can we predict for sure that in  
> future no type of functionality will require more stack. So taking  
> away 8Kb stack size on such arches solves no known problems and  
> introduces artificial limitations on code complexity.
>...

That's complete bullshit considering that we are talking about an
i386-only patch.

> Parag

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] i386: always use 4k stacks

[Parag Warudkar]

On Dec 18, 2005, at 10:57 AM, Adrian Bunk wrote:

> That's complete bullshit considering that we are talking about an
> i386-only patch.

Ok, ignore my rants, I wrongly assumed there is a drive to make all  
arches live with 4Kb! But if it's taking away the 8Kb option on i386  
please consider keeping the 8Kb option and making 4Kb default.

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Fri, Dec 16, 2005 at 04:35:03PM +0100, Diego Calleja wrote:
> El Fri, 16 Dec 2005 15:04:25 +0100,
> Adrian Bunk <bunk@stusta.de> escribió:
> 
> > My count of bug reports for problems with 4k stacks after Neil's patch
> > went into -mm is still at 0.
> > 
> > Either there are no problems left or noone pays attention to them since 
> > disabling 4k stacks "fixed" the problem.
> > 
> > In both cases there's no reason against applying my patch.
> 
> I know, but there's too much resistance to the "pure" 4kb patch. The
> 8 KB patch does the same thing (enables 4kb stacks)  and at the same
> time the 8kb groupies can't flamewar you for it, it covers akpm's

I have no problems with people flaming me.

I had problems if people would actually find technical reasons where my 
patch breaks in-kernel code.  ;-)

> concerns, it puts some pressure on the ndiswrapper guys and leaves
> time for the broadcom driver developers to finish, merge and push
> to the distributions their driver. The 8kb config option can be
> removed in the future when we're sure that it's 100% safe (neil
> brown's patch isn''t a good sign). It makes every happy IMO ;)

Neil's patch fixes the last known poroblems.

My count of bug reports for problems with 4k stacks after Neil's patch
went into -mm is still at 0.

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] i386: always use 4k stacks

[Arjan van de Ven]

On Fri, 2005-12-16 at 14:10 +0100, Diego Calleja wrote:
> El Thu, 15 Dec 2005 14:00:13 -0800,
> Andrew Morton <akpm@osdl.org> escribió:
> 
> 
> > Supporting 8k stacks is a small amount of code and nobody has seen a need
> > to make changes in there for quite a long time.  So there's little cost to
> > keeping the existing code.
> > 
> > And the existing code is useful:
> 
> Maybe this slighty different approach is better? 
> 
> 
> 
> Signed-off-by: Diego Calleja <diegocg@gmail.com>


I like this one; it makes the default 4K while leaving the 8K option for
those who really want it...

Acked-by: Arjan van de Ven <arjan@infradead.org>

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved at least
in -mm.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for Linus' 
tree.


Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjan@infradead.org>

---

This patch was already sent on:
- 5 Dec 2005
- 30 Nov 2005
- 23 Nov 2005
- 14 Nov 2005

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */

--- linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c.old	2005-12-11 15:10:27.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c	2005-12-11 15:11:29.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -55,10 +53,8 @@
 {	
 	/* high bits used in ret_from_ code */
 	int irq = regs->orig_eax & 0xff;
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -76,8 +72,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -104,7 +98,6 @@
 			: "memory", "cc", "ecx"
 		);
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -114,8 +107,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -200,7 +191,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

Re: [2.6 patch] i386: always use 4k stacks

[Jan Engelhardt]

>It seems most problems with 4k stacks are already resolved at least
>in -mm.
>
>I'd like to see this patch to always use 4k stacks in -mm now for 
>finding any remaining problems before submitting this patch for Linus' 
>tree.

By chance, I read that windows modules used in ndiswrapper
may require >4k-stacks. Will this become a problem?



Jan Engelhardt
-- 

Re: [2.6 patch] i386: always use 4k stacks

[Ismail Donmez]

Cuma 16 Aralık 2005 00:57 tarihinde şunları yazmıştınız:
> >It seems most problems with 4k stacks are already resolved at least
> >in -mm.
> >
> >I'd like to see this patch to always use 4k stacks in -mm now for
> >finding any remaining problems before submitting this patch for Linus'
> >tree.
>
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?

If 8k stacks get removed, yes. So if you have a chance to choose don't buy a 
wifi card which doesn't have a native linux driver.

Regards,
ismail

Re: [2.6 patch] i386: always use 4k stacks

[Puneet Vyas]

Ismail Donmez wrote:

>Cuma 16 Aralık 2005 00:57 tarihinde şunları yazmıştınız:
>  
>
>>>It seems most problems with 4k stacks are already resolved at least
>>>in -mm.
>>>
>>>I'd like to see this patch to always use 4k stacks in -mm now for
>>>finding any remaining problems before submitting this patch for Linus'
>>>tree.
>>>      
>>>
>>By chance, I read that windows modules used in ndiswrapper
>>may require >4k-stacks. Will this become a problem?
>>    
>>
>
>If 8k stacks get removed, yes. So if you have a chance to choose don't buy a 
>wifi card which doesn't have a native linux driver.
>
>  
>
If the learned folks here think that "ndiswrapper" is some user space 
program that people can live without than at least
3 people in my house are doomed. We like to use linux but do not have 
luxury that Ismail enjoys. At least windows
does not make such decisions on my behalf. Sigh.

~Puneet

Re: [2.6 patch] i386: always use 4k stacks

[Pekka Enberg]

Hi,

On 12/16/05, Puneet Vyas <puneetvyas@gmail.com> wrote:
> If the learned folks here think that "ndiswrapper" is some user space
> program that people can live without than at least
> 3 people in my house are doomed. We like to use linux but do not have
> luxury that Ismail enjoys. At least windows
> does not make such decisions on my behalf. Sigh.

While I understand that you're frustrated, please direct it towards
your vendor who is unwilling to open up the hardware documentation.
The binary-only drivers you are using are not supported on Linux (you
took them from Windows, remember) and the only way you're ever going
to get reliable wireless support is by reverse engineering or vendor
opening up the specs.

                                Pekka

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

Pekka Enberg wrote:

>Hi,
>
>On 12/16/05, Puneet Vyas <puneetvyas@gmail.com> wrote:
>  
>
>>If the learned folks here think that "ndiswrapper" is some user space
>>program that people can live without than at least
>>    
>>
ndiswrapper can be fixed to work in a 4k stack environment,
even if the windows driver in use needs more than 4k.  This
requires some work, because ndiswrapper will then have to
manage its own stack instead of simply using the provided
kernel stack.  It is up to all people who want ndiswrapper to
actually do this work.

Note that this work ought to be done anyway, as windows
drivers really assumes they can use 12k of stack, which they
cannot do even with the current 8k stack.

>>3 people in my house are doomed. We like to use linux but do not have
>>luxury that Ismail enjoys. At least windows
>>does not make such decisions on my behalf. Sigh.
>>    
>>
Windows makes a lot of such decisions - you just never see them
if you come from the windows world.  Could I run windows on my
machine with two keyboards, supporting two simultaneous users?
And in 64-bit mode too?  Not now. 

Could all the people with other non-x86 processors run windows? No.



>
>While I understand that you're frustrated, please direct it towards
>your vendor who is unwilling to open up the hardware documentation.
>The binary-only drivers you are using are not supported on Linux (you
>took them from Windows, remember) and the only way you're ever going
>to get reliable wireless support is by reverse engineering or vendor
>opening up the specs.
>
>                                Pekka
>-
>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/
>  
>

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

Puneet Vyas wrote:

> If the learned folks here think that "ndiswrapper" is some user space 
> program that people can live without than at least
> 3 people in my house are doomed. We like to use linux but do not have 
> luxury that Ismail enjoys. At least windows
> does not make such decisions on my behalf. Sigh.

ndiswrapper can be fixed to work in a 4k stack environment,
even if the windows driver in use needs more than 4k.  This
requires some work, because ndiswrapper will then have to
manage its own stack instead of simply using the provided
kernel stack.  It is up to all people who want ndiswrapper to
actually do this work.

Note that this work ought to be done anyway, as windows
drivers really assumes they can use 12k of stack, which they
cannot do even with the current 8k stack.

Another problem you may get with windows drivers, is licencing issues.
If they want to, they can set the licencing terms so that you
can't legally run the drivers on linux.  Currently, it is only a
question of money.  Buy a windows licence, an you can use the
windows driver on linux.  It may or may not stay that way.  Still, getting
what you want on linux will always be only a matter of money, as there
are wifi cards with _linux_ drivers out there.  Just buy the right ones
the next time you renew your pc.

Helge Hafting

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Thu, 2005-12-15 at 23:57 +0100, Jan Engelhardt wrote:
> >It seems most problems with 4k stacks are already resolved at least
> >in -mm.
> >
> >I'd like to see this patch to always use 4k stacks in -mm now for 
> >finding any remaining problems before submitting this patch for Linus' 
> >tree.
> 
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?

Please refer to the last 5 flamewars on this issue rather than starting
another one.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Iau, 2005-12-15 at 23:57 +0100, Jan Engelhardt wrote:
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?

For ndiswrapper to deal with internally. If you see the previous
'discussions' you'll see that is needed anyway as NT stacks are over 8K 

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

The issues with wireless drivers, as far as I've heard, still haven't been resolved. 

I've read all about the advantages of 4K, but, so far, no one has
really explained the _disadvantes_ to kernel developers of allowing
people to choose their own stack size.

-Alex

I code, therefore I am


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: [2.6 patch] i386: always use 4k stacks

[Helge Hafting]

On Mon, Dec 05, 2005 at 01:45:44PM -0800, Alex Davis wrote:
> The issues with wireless drivers, as far as I've heard, still haven't been resolved. 
> 
> I've read all about the advantages of 4K, but, so far, no one has
> really explained the _disadvantes_ to kernel developers of allowing
> people to choose their own stack size.
> 
The disadvantage of choice is that the kernel code gets more complicated.
8k stacks are two contigous pages.  So fork() have to ask for two
contigous pages, and handle cases where 8k is available but not contigous.
All that code disappear if the _choice_ is removed.  fork() and friends
will ask for 4k only - nothing special - and  either succeed or go OOM.

This was just an example, there are probably more to it.

With choice, people can have a fast 4k-stack kernel with all the advantages,
or an 8k-stack kernel that survives heavy stack usage.  But a developer
working on the VM system is slowed down by having to understand and consider 
both cases when making changes.  Someone considering only the 4k case
might break the 8k case and vice-versa.

I don't really know if we're ready for dropping 8k stack support.  
But when it happens, VM development will be a bit easier.  
Get enough such simplifications and it makes a real difference.
Collect enough choices & options, and it'll make a difference
the other way too.

Helge Hafting

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved at least
in -mm.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for Linus' 
tree.


Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjan@infradead.org>

---

This patch was already sent on:
- 30 Nov 2005
- 23 Nov 2005
- 14 Nov 2005

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */
--- linux-2.6.14-mm2-full/arch/i386/kernel/irq.c.old	2005-11-14 01:32:56.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/kernel/irq.c	2005-11-14 01:33:28.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -58,10 +56,8 @@
 #ifdef CONFIG_DEBUG_PREEMPT
 	u32 count = preempt_count() & PREEMPT_MASK;
 #endif
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -79,8 +75,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -118,7 +112,6 @@
 		irqctx->tinfo.preempt_count -= count;
 #endif
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -128,8 +121,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -228,7 +219,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved at least
in -mm.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for 2.6.16.


Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjan@infradead.org>

---

This patch was already sent on:
- 23 Nov 2005
- 14 Nov 2005

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */
--- linux-2.6.14-mm2-full/arch/i386/kernel/irq.c.old	2005-11-14 01:32:56.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/kernel/irq.c	2005-11-14 01:33:28.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -58,10 +56,8 @@
 #ifdef CONFIG_DEBUG_PREEMPT
 	u32 count = preempt_count() & PREEMPT_MASK;
 #endif
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -79,8 +75,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -118,7 +112,6 @@
 		irqctx->tinfo.preempt_count -= count;
 #endif
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -128,8 +121,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -228,7 +219,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for 2.6.16.


Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjan@infradead.org>

---

This patch was already sent on:
- 14 Nov 2005

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */
--- linux-2.6.14-mm2-full/arch/i386/kernel/irq.c.old	2005-11-14 01:32:56.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/kernel/irq.c	2005-11-14 01:33:28.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -58,10 +56,8 @@
 #ifdef CONFIG_DEBUG_PREEMPT
 	u32 count = preempt_count() & PREEMPT_MASK;
 #endif
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -79,8 +75,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -118,7 +112,6 @@
 		irqctx->tinfo.preempt_count -= count;
 #endif
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -128,8 +121,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -228,7 +219,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

Re: [2.6 patch] i386: always use 4k stacks

[Kenneth Parrish]

-=> In article 17 Nov 05, 06:17ish -0600 Kenneth Parrish wrote to All <=-

 AB> If one function calls another function you have to add the stack
 AB> usages.

[..]
> 78.5% of 493 make checkstack lines here report fewer than 200 bytes.
> Only six over 600.
Only six over 604. :)

--- MultiMail/Linux v0.46

Re: [2.6 patch] i386: always use 4k stacks

[Kenneth Parrish]

-=> In article 16 Nov 05  14:40:16, Adrian Bunk wrote to All <=-

 AB> If one function calls another function you have to add the stack
 AB> usages.

these few may do that, i bet.
 0xc02bb528 huft_build:                                  1432
 0xc02bb954 huft_build:                                  1432
 0xc02bc1c4 inflate_dynamic:                             1312
 0xc02bc2ff inflate_dynamic:                             1312
 0xc02bc082 inflate_fixed:                               1168
 0xc02bc172 inflate_fixed:                               1168

78.5% of 493 make checkstack lines here report fewer than 200 bytes.
Only six over 600.

... Life is like a simile.
--- MultiMail/Linux v0.46

Re: [2.6 patch] i386: always use 4k stacks

[Eric W. Biederman]

Kenneth Parrish <Kenneth.Parrish@familynet-international.net> writes:

> -=> In article 16 Nov 05  14:40:16, Adrian Bunk wrote to All <=-
>
>  AB> If one function calls another function you have to add the stack
>  AB> usages.
>
> these few may do that, i bet.
>  0xc02bb528 huft_build:                                  1432
>  0xc02bb954 huft_build:                                  1432
>  0xc02bc1c4 inflate_dynamic:                             1312
>  0xc02bc2ff inflate_dynamic:                             1312
>  0xc02bc082 inflate_fixed:                               1168
>  0xc02bc172 inflate_fixed:                               1168

Now what is interesting is these functions currently run with a 4KiB 
stack on every bootup.  So unless they have callers with a
significant stack footprint things are fine.

Eric

Re: [2.6 patch] i386: always use 4k stacks

[Jörn Engel]

On Wed, 30 November 2005 03:31:13 -0700, Eric W. Biederman wrote:
> Kenneth Parrish <Kenneth.Parrish@familynet-international.net> writes:
> 
> > -=> In article 16 Nov 05  14:40:16, Adrian Bunk wrote to All <=-
> >
> >  AB> If one function calls another function you have to add the stack
> >  AB> usages.
> >
> > these few may do that, i bet.
> >  0xc02bb528 huft_build:                                  1432
> >  0xc02bb954 huft_build:                                  1432
> >  0xc02bc1c4 inflate_dynamic:                             1312
> >  0xc02bc2ff inflate_dynamic:                             1312
> >  0xc02bc082 inflate_fixed:                               1168
> >  0xc02bc172 inflate_fixed:                               1168
> 
> Now what is interesting is these functions currently run with a 4KiB 
> stack on every bootup.  So unless they have callers with a
> significant stack footprint things are fine.

The longest call chain for these functions eats roughly 3.2k on i386
with allyesconfig.  Measured with a statical code checker, not tested.

Jörn

-- 
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra

Re: [2.6 patch] i386: always use 4k stacks

[Kenneth Parrish]

-=> In article 15 Nov 05  15:00:28, Adrian Bunk wrote to All <=-

[...]
 AB> Unconditionally enabling 4k stacks is the only way to achieve
 AB> this.
:) 2K might do here..

5 Tue Nov 15 19:29:43 ~/build/kernel/linux-2.6.15-rc1-git3 $ make checkstack
objdump -d vmlinux $(find . -name '*.ko') | \
perl /home/ken/build/kernel/linux-2.6.15-rc1-git3/scripts/checkstack.pl i386
0xc02bd528 huft_build:                                  1432
0xc02bd954 huft_build:                                  1432
0xc02be1c4 inflate_dynamic:                             1312
0xc02be2ff inflate_dynamic:                             1312
0xc02be082 inflate_fixed:                               1168
0xc02be172 inflate_fixed:                               1168
0x0000d748 ipv6_setsockopt:                             604
0x0000d788 ipv6_setsockopt:                             604
0xc0182a38 semctl_main:                                 588
0xc0182b11 semctl_main:                                 588
0xc022e938 ip_setsockopt:                               548
0xc022e9eb ip_setsockopt:                               548
0xc01831d4 sys_semtimedop:                              460
0xc01832d7 sys_semtimedop:                              460
0xc022f31d ip_getsockopt:                               436
0xc022f3b7 ip_getsockopt:                               436
0xc01b98de extract_buf:                                 424
0xc01b9818 extract_buf:                                 420
0xc0158ee4 sys_pivot_root:                              412
0xc0158f06 sys_pivot_root:                              412
0x0000e1a6 ipv6_getsockopt:                             392
0x0000e1e0 ipv6_getsockopt:                             392

... SPF  - Sender Policy Framework   [Electronic Mail]
--- MultiMail/Linux  Cyrix MII  1999 e-machines @ 200 MHz

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Wed, Nov 16, 2005 at 02:03:50AM +0000, Kenneth Parrish wrote:
> -=> In article 15 Nov 05  15:00:28, Adrian Bunk wrote to All <=-
> 
> [...]
>  AB> Unconditionally enabling 4k stacks is the only way to achieve
>  AB> this.
> :) 2K might do here..

No, it wouldn't.

If one function calls another function you have to add the stack usages.

> 5 Tue Nov 15 19:29:43 ~/build/kernel/linux-2.6.15-rc1-git3 $ make checkstack
> objdump -d vmlinux $(find . -name '*.ko') | \
> perl /home/ken/build/kernel/linux-2.6.15-rc1-git3/scripts/checkstack.pl i386
> 0xc02bd528 huft_build:                                  1432
> 0xc02bd954 huft_build:                                  1432
> 0xc02be1c4 inflate_dynamic:                             1312
> 0xc02be2ff inflate_dynamic:                             1312
> 0xc02be082 inflate_fixed:                               1168
> 0xc02be172 inflate_fixed:                               1168
>...

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] i386: always use 4k stacks

[Wed, 16 Nov 2005 00:41:11 +0100]

> documentation for broadcom wireless:
> http://bcm-specs.sipsolutions.net/
> embrionic driver based on this spec:
> http://bcm43xx.berlios.de/


Maybe a good deal would be to delay the 4K patch until some preliminary
version of those is merged? 

Re: [2.6 patch] i386: always use 4k stacks

[Parag Warudkar]

On Nov 15, 2005, at 6:41 PM, Wed, 16 Nov 2005 00:41:11 +0100 wrote:

>
>> documentation for broadcom wireless:
>> http://bcm-specs.sipsolutions.net/
>> embrionic driver based on this spec:
>> http://bcm43xx.berlios.de/
>
>
> Maybe a good deal would be to delay the 4K patch until some  
> preliminary
> version of those is merged?

Andi had some pretty valid comments against the 4K approach.
Here - http://lkml.org/lkml/2005/9/6/4
I didn't see anyone contradicting his opinion. Seems very plausible  
to me.

Parag

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Tue, 2005-11-15 at 18:56 -0500, Parag Warudkar wrote:
> On Nov 15, 2005, at 6:41 PM, Wed, 16 Nov 2005 00:41:11 +0100 wrote:
> 
> >
> >> documentation for broadcom wireless:
> >> http://bcm-specs.sipsolutions.net/
> >> embrionic driver based on this spec:
> >> http://bcm43xx.berlios.de/
> >
> >
> > Maybe a good deal would be to delay the 4K patch until some  
> > preliminary
> > version of those is merged?
> 
> Andi had some pretty valid comments against the 4K approach.
> Here - http://lkml.org/lkml/2005/9/6/4
> I didn't see anyone contradicting his opinion. Seems very plausible  
> to me.

the only argument I see is "we had overflows in 2.4 with 8k". In fact
that is part of why 4K stacks was done! With 4k/4k stacks there is MORE
stack space than in 2.4. Most of the overflows I've seen in 2.4 were
nested interrupts with complex softirqs; with the 4k/4k stack approach
interrupts have MORE stack space available than in 2.4, making overflows
less likely. In addition the 2.6 kernel has undergone a "stack diet",
the final piece of which is the IO submission change that is now in -mm.

Re: [2.6 patch] i386: always use 4k stacks

[Bernd Petrovitsch]

On Wed, 2005-11-16 at 00:41 +0100, Wed, 16 Nov 2005 00:41:11 +0100
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                   Interesting Name.
wrote:
> > documentation for broadcom wireless:
> > http://bcm-specs.sipsolutions.net/
> > embrionic driver based on this spec:
> > http://bcm43xx.berlios.de/
> 
> 
> Maybe a good deal would be to delay the 4K patch until some preliminary
> version of those is merged? 

Set the default value to "4k" and - to streß it further - remove the
questions on `make *config` so that sufficiently interesting people must
edit by hand after searching for it.
This will give the correct impression for everyone where it will go,
possibly raises the awareness of this area (WLAN drivers) and it doesn't
break ATM anything seriously.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Wed, Nov 16, 2005 at 10:04:14AM +0100, Bernd Petrovitsch wrote:
> On Wed, 2005-11-16 at 00:41 +0100, Wed, 16 Nov 2005 00:41:11 +0100
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                    Interesting Name.
> wrote:
> > > documentation for broadcom wireless:
> > > http://bcm-specs.sipsolutions.net/
> > > embrionic driver based on this spec:
> > > http://bcm43xx.berlios.de/
> > 
> > 
> > Maybe a good deal would be to delay the 4K patch until some preliminary
> > version of those is merged? 
> 
> Set the default value to "4k" and - to streß it further - remove the
> questions on `make *config` so that sufficiently interesting people must
> edit by hand after searching for it.

If you are sufficiently interested, reverting my patch would be more 
simple than manually hacking a Kconfig file.

> This will give the correct impression for everyone where it will go,
> possibly raises the awareness of this area (WLAN drivers) and it doesn't
> break ATM anything seriously.
> 
> 	Bernd

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] i386: always use 4k stacks

[Krzysztof Halasa]

Bernd Petrovitsch <bernd@firmix.at> writes:

> Set the default value to "4k" and - to streß it further - remove the
> questions on `make *config` so that sufficiently interesting people must
> edit by hand after searching for it.

Haven't Red Hat tested that long enough?
-- 
Krzysztof Halasa

Re: [2.6 patch] i386: always use 4k stacks

[Robert Hancock]

Giridhar Pemmasani wrote:
> Shouldn't I have to prevent scheduler from changing the tasks when executing
> Windows code? Otherwise, kernel gets wrong current thread information,
> which is based on stack pointer. This is the stumbling block for implementing
> private stacks.

As long as preemption is disabled when the driver code is executing I 
don't see how this would happen.. I don't know much of how ndiswrapper 
does things but if the driver calls back into your code then you'd just 
have to change the stack back before doing anything that could schedule.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
> Giridhar Pemmasani wrote:
> > Shouldn't I have to prevent scheduler from changing the tasks when executing
> > Windows code? Otherwise, kernel gets wrong current thread information,
> > which is based on stack pointer. This is the stumbling block for implementing
> > private stacks.
> 
> As long as preemption is disabled when the driver code is executing

Um, but it's really really bad for drivers to do that.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Robert Hancock]

Lee Revell wrote:
>>As long as preemption is disabled when the driver code is executing
> 
> Um, but it's really really bad for drivers to do that.

Normally yes.. but that may be a sacrifice that may have to be made 
considering what ndiswrapper is doing - inserting blobs of code into the 
kernel that were never designed to run there. I would think that would 
be something you would want to do with such a driver regardless of stack 
switching - do we have any way of knowing whether the Windows driver is 
doing some timing-dependent thing that will cause bad things to happen 
if we take away the CPU from it in the middle?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Lee Revell wrote:

> Um, but it's really really bad for drivers to do that.

Not really. The Windows driver calls kernel API (in this case ndiswraper
functions) whenever it needs to wait on an event, sleep etc. So if preempt
is enabled on the way back (from Windows driver to Linux kernel call), it
shouldn't be a problem as far as preempt is concerned.

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Mon, Nov 14, 2005 at 09:07:48PM -0500, Lee Revell wrote:
 > On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
 > > Giridhar Pemmasani wrote:
 > > > Shouldn't I have to prevent scheduler from changing the tasks when executing
 > > > Windows code? Otherwise, kernel gets wrong current thread information,
 > > > which is based on stack pointer. This is the stumbling block for implementing
 > > > private stacks.
 > > 
 > > As long as preemption is disabled when the driver code is executing
 > 
 > Um, but it's really really bad for drivers to do that.

And loading Windows drivers into the kernel isn't ?
I think we're already in no-mans land here.

Remember, we have no clue what those drivers are even doing.
Preemption is the least of its problems.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Dave Jones wrote:

>On Mon, Nov 14, 2005 at 09:07:48PM -0500, Lee Revell wrote:
> > On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
> > > Giridhar Pemmasani wrote:
> > > > Shouldn't I have to prevent scheduler from changing the tasks when executing
> > > > Windows code? Otherwise, kernel gets wrong current thread information,
> > > > which is based on stack pointer. This is the stumbling block for implementing
> > > > private stacks.
> > > 
> > > As long as preemption is disabled when the driver code is executing
> > 
> > Um, but it's really really bad for drivers to do that.
>
>And loading Windows drivers into the kernel isn't ?
>I think we're already in no-mans land here.
>
>Remember, we have no clue what those drivers are even doing.
>Preemption is the least of its problems.
>
>		Dave
>
>
>  
>

NetWare used 16K stacks in kernel by default. 4K is not enough room. I 
have to dance around a lot of issues with 4K stacks. I haven't followed
who came up with the idea to limit stacks to 4K, but they should have 
the option of 4-16K. NeWare 5.0 started using 32 Stacks for
all the compression support and FS crap, but 16K was a good number.

Why does the kernel need to be limited to 4K? for kernel preemption?

Someone needs to fix this. It's busted. It makes porting code between 
Windows and Linux and other OS's difficult to support.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:

 > NetWare used 16K stacks in kernel by default.

unsubscribe netware-kernel

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Dave Jones wrote:

>On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
>
> > NetWare used 16K stacks in kernel by default.
>
>unsubscribe netware-kernel
>  
>

Making the point that in 1990, folks had grown beyond 4K stacks in 
kernels, along with MS DOS 640K Limitations.

:-)

Jeff

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

Re: [2.6 patch] i386: always use 4k stacks

[Neil Brown]

On Monday November 14, jmerkey@wolfmountaingroup.com wrote:
> Dave Jones wrote:
> 
> >On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
> >
> > > NetWare used 16K stacks in kernel by default.
> >
> >unsubscribe netware-kernel
> >  
> >
> 
> Making the point that in 1990, folks had grown beyond 4K stacks in 
> kernels, along with MS DOS 640K Limitations.

But I seem to remember learning in CS101 (or whatever we called it),
that the stack grows down and the heap grows up.
So if 'folks had grown beyond 4K stacks', I guess they must be at 2K
stacks ?->

NeilBrown

> 
> :-)
> 
> Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Neil Brown wrote:

>On Monday November 14, jmerkey@wolfmountaingroup.com wrote:
>  
>
>>Dave Jones wrote:
>>
>>    
>>
>>>On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
>>>
>>>      
>>>
>>>>NetWare used 16K stacks in kernel by default.
>>>>        
>>>>
>>>unsubscribe netware-kernel
>>> 
>>>
>>>      
>>>
>>Making the point that in 1990, folks had grown beyond 4K stacks in 
>>kernels, along with MS DOS 640K Limitations.
>>    
>>
>
>But I seem to remember learning in CS101 (or whatever we called it),
>that the stack grows down and the heap grows up.
>So if 'folks had grown beyond 4K stacks', I guess they must be at 2K
>stacks ?->
>
>NeilBrown
>  
>

Great point, and you are correct that MS DOS had bigger stacks than 4K. 
Onward through the fog ....

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Tue, 15 Nov 2005 14:18:51 +0100]

El Mon, 14 Nov 2005 23:47:10 -0700,
"Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> escribió:

> Great point, and you are correct that MS DOS had bigger stacks than 4K. 
> Onward through the fog ....


And Linux had stacks bigger than 4K until recently and could be made
bigger again. But 4K stacks are not considered a regression, but a
feature (ie: a good thing). So I guess you're not impressing lots 
of people saying that msdos had bigger stacks...

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Tue, 2005-11-15 at 14:18 +0100, Tue, 15 Nov 2005 14:18:51 +0100
wrote:
> El Mon, 14 Nov 2005 23:47:10 -0700,
> "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> escribió:
> 
> > Great point, and you are correct that MS DOS had bigger stacks than 4K. 
> > Onward through the fog ....
> 
> 
> And Linux had stacks bigger than 4K until recently and could be made
> bigger again. 

well ......

in 2.4 kernels you had a 4K stack as well (even though it was 8Kb in
size, you lost 1.5Kb to the task struct and you lost 2 to 2.5 Kb to irq
context, net usable was 4Kb). In 2.6 the task struct moved off the
stack, and the 4KSTACK feature allowed you to split the irq stack usage
off to a seperate stack, still giving you 4Kb available.. that's still
the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
soon) an option to get 6Kb effective stack space instead. This is an
increase of 2Kb compared to 2.4. 

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Arjan van de Ven wrote:

> the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> soon) an option to get 6Kb effective stack space instead. This is an
> increase of 2Kb compared to 2.4.

It has been asked couple of times before in this context and no one cared to
answer:

Using 4k stacks may have advantages, but what compelling reasons are there
to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
throw away the option of 8k stacks, especially since the impact of this
option on the kernel implementation is very little?

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Tue, Nov 15, 2005 at 11:46:30AM -0500, Giridhar Pemmasani wrote:
> Arjan van de Ven wrote:
> 
> > the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> > soon) an option to get 6Kb effective stack space instead. This is an
> > increase of 2Kb compared to 2.4.
> 
> It has been asked couple of times before in this context and no one cared to
> answer:
> 
> Using 4k stacks may have advantages, but what compelling reasons are there
> to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
> throw away the option of 8k stacks, especially since the impact of this
> option on the kernel implementation is very little?


One important point is to get remaining problems reported:

All the known issues in e.g. xfs, dm or reiser4 should have been 
addressed.

But how many issues have never been reported because people noticed that 
disabling CONFIG_4KSTACKS fixed the problem for them and therefore 
didn't report it?

I experienced something similar with my patch to schedule OSS drivers 
with ALSA replacements for removal - when someone reported he needed an 
OSS driver for $reason I asked him for bug numbers in the ALSA bug 
tracking system - and the highest number were 4 new bugs against one 
ALSA driver.

Unconditionally enabling 4k stacks is the only way to achieve this.


And the fact that it might force people to help with the development or 
at least use open source drivers for their hardware instead of 
binary-only Windows drivers isn't exactly a disadvantage for the 
development of Linux.


> Giri

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] i386: always use 4k stacks

[Giridhar Pemmasani]

On Tue, 15 Nov 2005 19:55:43 +0100, Adrian Bunk <bunk@stusta.de> said:

  Adrian> And the fact that it might force people to help with the
  Adrian> development or at least use open source drivers for their
  Adrian> hardware instead of binary-only Windows drivers isn't
  Adrian> exactly a disadvantage for the development of Linux.

IMO, this is at best only one side of the coin: Many people that ask
for help with ndiswrapper seem to be newbies that have just begun
using Linux. Most of these people can't/won't help with development of
native drivers. On the other hand, ndiswrapper can be used in reverse
engineering. I know of at least two such cases. So thinking
ndiswrapper as a scourge that hinders development (I am exaggerating a
bit here, but it has been suggested so by certain people more than
once on lkml) is not correct. Informed users, especially those that
follow lkml, are more interested in helping development of native
drivers and would chose to use native drivers if possible. Leaving
other end users high and dry without wireless support until such
drivers are available is not necessarily helpful for development of
open source drivers.

In essence, ndiswrapper is for those chipsets that have no open source
drivers until one can be developed.

This issue raises a concern for me as developer of ndiswrapper. I
perceive that some kernel developers have strong opinions against
ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
vested interests in ndiswrapper, although it will be sad to see lot of
effort and time put into ndiswrapper go waste. However, I believe
there is a need for such a project: There is a company (Linuxant) that
sells a product similar to ndiswrapper, ndisulator, which is similar
to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
has been downloaded more than half a million times from Sourceforge
alone. And not all native drivers support all the features that users
need, e.g., WPA, whereas ndiswrapper supports all features provided by
vendor for Windows driver. And there are chipsets for which open
source drivers may not be available ever since they are rare. And if
it takes many months/years to develop a stable open source driver,
users need some way of using their hardware until then. And so on. I
am not trying to argue in favor of ndiswrapper at the cost of open
source drivers, but that there is a genuine need for such a project,
at least for now.

This is neither a complaint nor a plea; if option to chose 8k stacks
is dropped in the kernel, so be it. If I find time to provide support
for private 8k stacks within ndiswrapper, I will do that, so that if
this patch makes into kernel, users who need some way of using the
wireless cards can do so, for now.

  Adrian> Unconditionally enabling 4k stacks is the only way to
  Adrian> achieve this.

I think this is a bit drastic. As I suggested earlier, making 4k
stacks the default may be enough. For example, RedHat already
distributes kernels with 4k stacks and I am not sure if you will get
lot more cases, considering the popularity of RedHat.

-- 
Giri

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Tue, Nov 15, 2005 at 05:27:10PM -0500, Giridhar Pemmasani wrote:
> On Tue, 15 Nov 2005 19:55:43 +0100, Adrian Bunk <bunk@stusta.de> said:
> 
>   Adrian> And the fact that it might force people to help with the
>   Adrian> development or at least use open source drivers for their
>   Adrian> hardware instead of binary-only Windows drivers isn't
>   Adrian> exactly a disadvantage for the development of Linux.
> 
> IMO, this is at best only one side of the coin: Many people that ask
> for help with ndiswrapper seem to be newbies that have just begun
> using Linux. Most of these people can't/won't help with development of
> native drivers. On the other hand, ndiswrapper can be used in reverse
> engineering. I know of at least two such cases. So thinking
> ndiswrapper as a scourge that hinders development (I am exaggerating a
> bit here, but it has been suggested so by certain people more than
> once on lkml) is not correct. Informed users, especially those that
> follow lkml, are more interested in helping development of native
> drivers and would chose to use native drivers if possible. Leaving
> other end users high and dry without wireless support until such
> drivers are available is not necessarily helpful for development of
> open source drivers.

My impression is more that there is a big demand for ndiswrapper (look 
e.g. at your download numbers below and some statements in this thread) 
while support for the people developing open source drivers isn't that 
big.

> In essence, ndiswrapper is for those chipsets that have no open source
> drivers until one can be developed.

In essency, ndiswrapper is a good excuse for hardware vendors who do not 
want to support the development of open source drivers, because they can 
always tell their costumers "Our hardware is supported by Linux through 
the open source ndiswrapper module".

> This issue raises a concern for me as developer of ndiswrapper. I
> perceive that some kernel developers have strong opinions against
> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
> vested interests in ndiswrapper, although it will be sad to see lot of
> effort and time put into ndiswrapper go waste. However, I believe

My personal opinion is that the ability to use unmodified binary-only 
Windows drivers under Linux is really a cool project - and this is meant 
in a 100% positive sense.

But a side effect is a worse open source support for the hardware in 
question.

> there is a need for such a project: There is a company (Linuxant) that
> sells a product similar to ndiswrapper, ndisulator, which is similar
> to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
> has been downloaded more than half a million times from Sourceforge
> alone. And not all native drivers support all the features that users
> need, e.g., WPA, whereas ndiswrapper supports all features provided by
> vendor for Windows driver. And there are chipsets for which open
> source drivers may not be available ever since they are rare. And if
> it takes many months/years to develop a stable open source driver,
> users need some way of using their hardware until then. And so on. I
> am not trying to argue in favor of ndiswrapper at the cost of open
> source drivers, but that there is a genuine need for such a project,
> at least for now.

As I tried to express above, both current end users and hardware vendors 
might like ndiswrapper, but as a side effect there are less and/or worse 
open source drivers.

It partially boils down to the question whether it's better for Linux to 
get as much hardware supported now no matter how, or whether it's better 
to have less hardware supported with good open source drivers and with 
end users putting pressure on hardware vendors to help people developing 
open source drivers.

And there's also the side effect that a poorly written Windows driver 
might crash the Linux kernel. Many end users will attribute such a crash 
to the Linux kernel harming the reputation of Linux as being stable.

> This is neither a complaint nor a plea; if option to chose 8k stacks
> is dropped in the kernel, so be it. If I find time to provide support
> for private 8k stacks within ndiswrapper, I will do that, so that if
> this patch makes into kernel, users who need some way of using the
> wireless cards can do so, for now.
>...

It's not the main purpose of my patch to break ndiswrapper, that is a 
collateral damage - but IMHO a positive one.

And we are talking about open source.

You are free to solve the stack problem in ndiswrapper (which might 
already be requierd for some drivers that aren't even happy with the 
current stack limit), or you can tell people to undo my patch or 
whatever.

> Giri

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] i386: always use 4k stacks

[Denis Vlasenko]

On Wednesday 16 November 2005 00:27, Giridhar Pemmasani wrote:
> In essence, ndiswrapper is for those chipsets that have no open source
> drivers until one can be developed.
> 
> This issue raises a concern for me as developer of ndiswrapper. I
> perceive that some kernel developers have strong opinions against
> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
> vested interests in ndiswrapper, although it will be sad to see lot of
> effort and time put into ndiswrapper go waste.

Does it mean that you support ndiswrapper just because you wrote it?
I understand this, but it's not a valid technical reason why
it should be supported.

> However, I believe 
> there is a need for such a project: There is a company (Linuxant) that
> sells a product similar to ndiswrapper, ndisulator, which is similar
> to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
> has been downloaded more than half a million times from Sourceforge
> alone. And not all native drivers support all the features that users
> need, e.g., WPA, whereas ndiswrapper supports all features provided by
> vendor for Windows driver. And there are chipsets for which open
> source drivers may not be available ever since they are rare. And if
> it takes many months/years to develop a stable open source driver,
> users need some way of using their hardware until then.

Companies got nice excuse for not giving us docs, making those
months/years even longer.

> And so on. I 
> am not trying to argue in favor of ndiswrapper at the cost of open
> source drivers, but that there is a genuine need for such a project,
> at least for now.

Ok, how can we make any progress on obtaining docs for TI acx wireless
chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
driver already exists (ndiswrapper), go away".

BTW, a few of wireless developers are interested in writing _open source
firmware_ (not just driver) for these, and it is not that hard to do,
if only we had the docs on components which make up the device.
Both of those are based on ARM processor + some specialized chips.

How can we hope to persuade companies into releasing that info
when they are escaping from giving us even docs on "external" interface
to their firmware with ndiswrapper argument, let alone on "internal"
components?

> This is neither a complaint nor a plea; if option to chose 8k stacks
> is dropped in the kernel, so be it. If I find time to provide support
> for private 8k stacks within ndiswrapper, I will do that, so that if
> this patch makes into kernel, users who need some way of using the
> wireless cards can do so, for now.
> 
>   Adrian> Unconditionally enabling 4k stacks is the only way to
>   Adrian> achieve this.
> 
> I think this is a bit drastic. As I suggested earlier, making 4k
> stacks the default may be enough. For example, RedHat already
> distributes kernels with 4k stacks and I am not sure if you will get
> lot more cases, considering the popularity of RedHat.
--
vda

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Denis Vlasenko wrote:

>> This issue raises a concern for me as developer of ndiswrapper. I
>> perceive that some kernel developers have strong opinions against
>> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
>> vested interests in ndiswrapper, although it will be sad to see lot of
>> effort and time put into ndiswrapper go waste.
> 
> Does it mean that you support ndiswrapper just because you wrote it?
> I understand this, but it's not a valid technical reason why
> it should be supported.

What logic did you use to infer that? I only said I am continuing to develop
ndiswrapper. "Vested interests" comment is to indicate that I have nothing
to gain by supporting ndiswrapper in Linux kernel; I am doing what I can so
people with unsupported wireless cards can use them in Linux.
 
> Companies got nice excuse for not giving us docs, making those
> months/years even longer.
> 
>> And so on. I
>> am not trying to argue in favor of ndiswrapper at the cost of open
>> source drivers, but that there is a genuine need for such a project,
>> at least for now.
> 
> Ok, how can we make any progress on obtaining docs for TI acx wireless
> chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
> driver already exists (ndiswrapper), go away".

TI ACX chipset has been out long before ndiswrapper supported it. It has
been years since that chipset is out. In fact, ACX 100 chipset is no longer
made. Still the open source driver doesn't support WEP/WPA (I could be
wrong about current status, but at least until recently it was not). As I
said before, ndiswrapper is not competition to open source drivers - if
anything, it could be used to understand what the Windows driver does and
that may help in developing/improving open source driver.

> BTW, a few of wireless developers are interested in writing _open source
> firmware_ (not just driver) for these, and it is not that hard to do,
> if only we had the docs on components which make up the device.

I agree. But that is big "if".

> How can we hope to persuade companies into releasing that info
> when they are escaping from giving us even docs on "external" interface
> to their firmware with ndiswrapper argument, let alone on "internal"
> components?

This argument is debatable: There are wireless cards that didn't have
drivers even before ndiswrapper supported them. To claim that if they are
supported with anything less than an open source driver is hurting Linux is
one opinion. Given a choice, many people (I myself included) would chose
open source driver, but there are others that want to use the hardware they
have in Linux right now. Until an open source driver is available, I am
helping provide support for some hardware, so such people can use that
hardware in Linux.

I also would like to point out that using NDIS drivers in Linux is not
exactly same as using binary drivers: Whereas full-binary drivers hide
everything, NDIS drivers use an API to support the hardware (e.g., to
obtain/release a spinlcok, allocate/free memory etc). ndiswrapper
implements that API, so one can understand what an NDIS driver is doing at
the level of that API. 

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Denis Vlasenko wrote:

>> This issue raises a concern for me as developer of ndiswrapper. I
>> perceive that some kernel developers have strong opinions against
>> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
>> vested interests in ndiswrapper, although it will be sad to see lot of
>> effort and time put into ndiswrapper go waste.
> 
> Does it mean that you support ndiswrapper just because you wrote it?
> I understand this, but it's not a valid technical reason why
> it should be supported.

What logic did you use to infer that? I only said I am continuing to develop
ndiswrapper and "vested interests" comment is to indicate that I have
nothing to gain by supporting ndiswrapper in Linux kernel; I am doing what
I can so people with unsupported wireless cards can use them in Linux.

> Companies got nice excuse for not giving us docs, making those
> months/years even longer.
> 
>> And so on. I
>> am not trying to argue in favor of ndiswrapper at the cost of open
>> source drivers, but that there is a genuine need for such a project,
>> at least for now.

TI ACX chipset has been out long before ndiswrapper supported it. It has
been years since that chipset is out. In fact, ACX 100 chipset is no longer
made. Still the open source driver doesn't support WEP/WPA (I could be
wrong about current status, but at least until recently it was not). As I
said before, ndiswrapper is not competition to open source drivers - if
anything, it could be used to understand what the Windows driver does and
that may help in developing/improving open source driver.

> BTW, a few of wireless developers are interested in writing _open source
> firmware_ (not just driver) for these, and it is not that hard to do,
> if only we had the docs on components which make up the device.

I agree. But that is big "if".

> How can we hope to persuade companies into releasing that info
> when they are escaping from giving us even docs on "external" interface
> to their firmware with ndiswrapper argument, let alone on "internal"
> components?

This argument is debatable: There are wireless cards that didn't have
drivers even before ndiswrapper supported them. To claim that if they are
supported with anything less than an open source driver is hurting Linux is
one opinion. Given a choice, many people (I myself included) would chose
open source driver, but there are others that want to use the hardware they
have in Linux right now. Until an open source driver is available, I am
helping provide support for some hardware, so such people can use that
hardware in Linux.

I also would like to point out that using NDIS drivers in Linux is not
exactly same as using binary drivers: Whereas full-binary drivers hide
everything, NDIS drivers use an API to do anything/everything from the
kernel (e.g., to obtain/release a spinlcok, allocate/free memory etc).
ndiswrapper implements that API, so one can understand what an NDIS driver
is doing at the level of that API. In a way it is similar to loading
firmware (that runs on CPU) into open source driver.

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Bill Davidsen]

Adrian Bunk wrote:
> On Tue, Nov 15, 2005 at 11:46:30AM -0500, Giridhar Pemmasani wrote:
> 
>>Arjan van de Ven wrote:
>>
>>
>>>the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
>>>soon) an option to get 6Kb effective stack space instead. This is an
>>>increase of 2Kb compared to 2.4.
>>
>>It has been asked couple of times before in this context and no one cared to
>>answer:
>>
>>Using 4k stacks may have advantages, but what compelling reasons are there
>>to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
>>throw away the option of 8k stacks, especially since the impact of this
>>option on the kernel implementation is very little?
> 
> 
> 
> One important point is to get remaining problems reported:
> 
> All the known issues in e.g. xfs, dm or reiser4 should have been 
> addressed.
> 
> But how many issues have never been reported because people noticed that 
> disabling CONFIG_4KSTACKS fixed the problem for them and therefore 
> didn't report it?
> 
> I experienced something similar with my patch to schedule OSS drivers 
> with ALSA replacements for removal - when someone reported he needed an 
> OSS driver for $reason I asked him for bug numbers in the ALSA bug 
> tracking system - and the highest number were 4 new bugs against one 
> ALSA driver.
> 
> Unconditionally enabling 4k stacks is the only way to achieve this.

The problem is that you persist in saying "the only way to achieve this" 
without admiting that some people are questioning the need to run in 4k 
stacks. The only argument I have seen for 4k stacks is that memory is 
allocated in 4k blocks and there might not be 8k contiguous available. 
When that's true the system is probably in deep trouble on memory anyway.

As someone pointed out using a larger memory allocation block (ie. 
multiple of hardware minimum page) would avoid the fragmentation, make 
all the bitmaps smaller, and generally have minimal effect either way on 
memory use. And you could make the stack size the memory allocation 
block size and never have to do conversions. Then the allocation size 
could be anything reasonable, from 4k to 32k as mentioned recently. 
Given the memory size of typical computers today, saving a few K per 
process matters as much as a beer fart in a cow barn.

Do all other non-x86 platforms use 4k stacks? Then why is it such a big 
thing to do it as the only choice for x86?

It seems like a lot of effort is being spent making things run in 4k 
stacks, with minimal consideration of what benefits are gained or if 
there are other ways to gain them. It just feels as though it's being 
done to prove it's possible. Linux is about choice, let's go back to that.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Bill Davidsen wrote:


> process matters as much as a beer fart in a cow barn.

This one cracked me up :-)

> It seems like a lot of effort is being spent making things run in 4k
> stacks, with minimal consideration of what benefits are gained or if
> there are other ways to gain them. It just feels as though it's being
> done to prove it's possible. Linux is about choice, let's go back to that.

I couldn't agree more.

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Rob Landley]

On Tuesday 15 November 2005 12:55, Adrian Bunk wrote:
> I experienced something similar with my patch to schedule OSS drivers
> with ALSA replacements for removal - when someone reported he needed an
> OSS driver for $reason I asked him for bug numbers in the ALSA bug
> tracking system - and the highest number were 4 new bugs against one
> ALSA driver.

Speaking of which: I've been playing with qemu recently, and the sound card it 
emulates is a sound blaster 16.  Which only seems to have an OSS driver, no 
ALSA...

This is known?  If so I might take a whack at porting this if I get really 
bored this weekend...

Rob

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Fri, 2005-11-18 at 19:33 -0600, Rob Landley wrote:
> On Tuesday 15 November 2005 12:55, Adrian Bunk wrote:
> > I experienced something similar with my patch to schedule OSS drivers
> > with ALSA replacements for removal - when someone reported he needed an
> > OSS driver for $reason I asked him for bug numbers in the ALSA bug
> > tracking system - and the highest number were 4 new bugs against one
> > ALSA driver.
> 
> Speaking of which: I've been playing with qemu recently, and the sound card it 
> emulates is a sound blaster 16.  Which only seems to have an OSS driver, no 
> ALSA...
> 
> This is known?  If so I might take a whack at porting this if I get really 
> bored this weekend...

There already is an ALSA driver, check out sound/isa/sb/sb16.c:

/*
 *  Driver for SoundBlaster 16/AWE32/AWE64 soundcards
 *  Copyright (c) by Jaroslav Kysela <perex@suse.cz>

etc

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Rob Landley]

On Friday 18 November 2005 20:02, Lee Revell wrote:
> > Speaking of which: I've been playing with qemu recently, and the sound
> > card it emulates is a sound blaster 16.  Which only seems to have an OSS
> > driver, no ALSA...
> >
> > This is known?  If so I might take a whack at porting this if I get
> > really bored this weekend...
>
> There already is an ALSA driver, check out sound/isa/sb/sb16.c:

Ok, so where is the config option?

find . | xargs grep CONFIG_SND_SB16
./arch/i386/defconfig:# CONFIG_SND_SB16 is not set
./arch/ppc/configs/common_defconfig:# CONFIG_SND_SB16 is not set
./arch/ppc/configs/power3_defconfig:# CONFIG_SND_SB16 is not set
./include/sound/sb.h:   void *csp; /* used only when CONFIG_SND_SB16_CSP is 
set */
./sound/isa/sb/Makefile:obj-$(CONFIG_SND_SB16) += snd-sb16.o snd-sb16-dsp.o 
snd-sb-common.o
./sound/isa/sb/Makefile:ifeq ($(CONFIG_SND_SB16_CSP),y)
./sound/isa/sb/Makefile:  obj-$(CONFIG_SND_SB16) += snd-sb16-csp.o
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16_main.c:#ifdef CONFIG_SND_SB16_CSP

It's in defconfig, source, and the makefile, but nowhere in Kconfig...

Rob

Re: [2.6 patch] i386: always use 4k stacks

[Lee Revell]

On Fri, 2005-11-18 at 20:43 -0600, Rob Landley wrote:
> On Friday 18 November 2005 20:02, Lee Revell wrote:
> > > Speaking of which: I've been playing with qemu recently, and the sound
> > > card it emulates is a sound blaster 16.  Which only seems to have an OSS
> > > driver, no ALSA...
> > >
> > > This is known?  If so I might take a whack at porting this if I get
> > > really bored this weekend...
> >
> > There already is an ALSA driver, check out sound/isa/sb/sb16.c:
> 
> Ok, so where is the config option?
> 

sound/isa/Kconfig:

253 config SND_SB16
254         tristate "Sound Blaster 16 (PnP)"
255         depends on SND
256         select SND_OPL3_LIB
257         select SND_MPU401_UART
258         select SND_PCM
259         select SND_GENERIC_DRIVER
260         help
261           Say Y here to include support for Sound Blaster 16 soundcards
262           (including the Plug and Play version).
263 
264           To compile this driver as a module, choose M here: the module
265           will be called snd-sb16.

Lee

Re: [2.6 patch] i386: always use 4k stacks

[Rob Landley]

On Friday 18 November 2005 21:22, Lee Revell wrote:
> On Fri, 2005-11-18 at 20:43 -0600, Rob Landley wrote:
> > On Friday 18 November 2005 20:02, Lee Revell wrote:
> > > > Speaking of which: I've been playing with qemu recently, and the
> > > > sound card it emulates is a sound blaster 16.  Which only seems to
> > > > have an OSS driver, no ALSA...
> > > >
> > > > This is known?  If so I might take a whack at porting this if I get
> > > > really bored this weekend...
> > >
> > > There already is an ALSA driver, check out sound/isa/sb/sb16.c:
> >
> > Ok, so where is the config option?
>
> sound/isa/Kconfig:

Ah, I see.

that entire menu doesn't show up unless you've selected ISA under the bus menu 
(which I thought means we probe for ISA slots, not that we don't support ISA 
devices built onto the motherboard).

Meanwhile, the OSS SB16 driver shows up just fine with ISA disabled in the bus 
menu...

Rob

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Fri, Nov 18, 2005 at 09:38:29PM -0600, Rob Landley wrote:

 > that entire menu doesn't show up unless you've selected ISA under the bus menu 
 > (which I thought means we probe for ISA slots, not that we don't support ISA 
 > devices built onto the motherboard).

Common misconception.  CONFIG_ISA means "Show me drivers that need
an ISA bus". Nothing more, nothing less.

You can't actually probe for the existance of an ISA slot, only
(unsafely) probe for a specific ISA device by poking ports.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Rob Landley]

On Tuesday 15 November 2005 10:46, Giridhar Pemmasani wrote:
> Arjan van de Ven wrote:
> > the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> > soon) an option to get 6Kb effective stack space instead. This is an
> > increase of 2Kb compared to 2.4.
>
> It has been asked couple of times before in this context and no one cared
> to answer:
>
> Using 4k stacks may have advantages, but what compelling reasons are there
> to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
> throw away the option of 8k stacks, especially since the impact of this
> option on the kernel implementation is very little?

Once everything in the kernel tree has been cleaned up to work with 4k stacks, 
then none of the in-kernel drivers need this option.  No future kernel 
drivers will be accepted into the tree if they don't work with 4k stacks, 
either.  Therefore, the 8k stack option becomes something _only_ needed for 
out-of-tree drivers, and if out-of-tree drivers need >4k stacks they can 
maintain the 8k patch out of tree along with said driver.

Why is this difficult to understand?  The "impact on the implementation" of 
having 100 extra exports of random internal kernel symbols is fairly small as 
well (from a lines of code perspective), but on a policy level it ain't gonna 
happen.

Rob

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Llu, 2005-11-14 at 23:19 -0700, Jeff V. Merkey wrote:
> Making the point that in 1990, folks had grown beyond 4K stacks in 
> kernels, along with MS DOS 640K Limitations.

And Linux 8086 uses 512 byte kernel stacks, and really wants a bit of
tuning to get down to 256.

Its about discipline and design not year

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Alan Cox wrote:

>On Llu, 2005-11-14 at 23:19 -0700, Jeff V. Merkey wrote:
>  
>
>>Making the point that in 1990, folks had grown beyond 4K stacks in 
>>kernels, along with MS DOS 640K Limitations.
>>    
>>
>
>And Linux 8086 uses 512 byte kernel stacks, and really wants a bit of
>tuning to get down to 256.
>
>Its about discipline and design not year
>
>-
>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/
>
>  
>
Amen.

:-)

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

This will break ndiswrapper. Why can't we just leave this in and let people choose? 

I code, therefore I am


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> This will break ndiswrapper. Why can't we just leave this in and let people choose? 

If we spent our entire lives waiting for people to fix code nothing
would ever happen. Removing 8K stacks is a good thing to do for many
reasons. The ndis wrapper people have known it is coming for a long
time, and if it has a lot of users I'm sure someone in that community
will take the time to make patches.

Re: [2.6 patch] i386: always use 4k stacks

[Alistair John Strachan]

On Monday 14 November 2005 14:49, Alan Cox wrote:
> On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> > This will break ndiswrapper. Why can't we just leave this in and let
> > people choose?
>
> If we spent our entire lives waiting for people to fix code nothing
> would ever happen. Removing 8K stacks is a good thing to do for many
> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.

I honestly don't know if this is the case, but is it conceivable that no patch 
could be written to resolve this, because the Windows drivers themselves only 
respect Windows stack limits (which are presumably still 8K?).

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> I honestly don't know if this is the case, but is it conceivable that no patch 
> could be written to resolve this, because the Windows drivers themselves only 
> respect Windows stack limits (which are presumably still 8K?).

afaik Windows has 12k or 16k stacks.

Re: [2.6 patch] i386: always use 4k stacks

[Dave Jones]

On Mon, Nov 14, 2005 at 06:02:45PM +0000, Alistair John Strachan wrote:
 > On Monday 14 November 2005 14:49, Alan Cox wrote:
 > > On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
 > > > This will break ndiswrapper. Why can't we just leave this in and let
 > > > people choose?
 > >
 > > If we spent our entire lives waiting for people to fix code nothing
 > > would ever happen. Removing 8K stacks is a good thing to do for many
 > > reasons. The ndis wrapper people have known it is coming for a long
 > > time, and if it has a lot of users I'm sure someone in that community
 > > will take the time to make patches.
 > 
 > I honestly don't know if this is the case, but is it conceivable that no patch 
 > could be written to resolve this, because the Windows drivers themselves only 
 > respect Windows stack limits (which are presumably still 8K?).

Windows drivers can actually use more than 8KB. So in some situations,
you're already screwed.  There are already cases where vendors customer
service are now telling people "Use ndiswrapper" when people ask about
Linux support.

If we continue down this path, we'll have no native wireless drivers for Linux.
The answer is not to complain to linux-kernel for breaking ndiswrapper,
but complain to the vendors for not releasing specifications for
native drivers to be written.

		Dave

Re: [2.6 patch] i386: always use 4k stacks

[Alistair John Strachan]

On Monday 14 November 2005 18:18, Dave Jones wrote:
> On Mon, Nov 14, 2005 at 06:02:45PM +0000, Alistair John Strachan wrote:
>  > On Monday 14 November 2005 14:49, Alan Cox wrote:
>  > > On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
>  > > > This will break ndiswrapper. Why can't we just leave this in and let
>  > > > people choose?
>  > >
>  > > If we spent our entire lives waiting for people to fix code nothing
>  > > would ever happen. Removing 8K stacks is a good thing to do for many
>  > > reasons. The ndis wrapper people have known it is coming for a long
>  > > time, and if it has a lot of users I'm sure someone in that community
>  > > will take the time to make patches.
>  >
>  > I honestly don't know if this is the case, but is it conceivable that no
>  > patch could be written to resolve this, because the Windows drivers
>  > themselves only respect Windows stack limits (which are presumably still
>  > 8K?).
>
> Windows drivers can actually use more than 8KB. So in some situations,
> you're already screwed.  There are already cases where vendors customer
> service are now telling people "Use ndiswrapper" when people ask about
> Linux support.
>
> If we continue down this path, we'll have no native wireless drivers for
> Linux. The answer is not to complain to linux-kernel for breaking
> ndiswrapper, but complain to the vendors for not releasing specifications
> for native drivers to be written.

I agree, and I was not arguing for or against breaking ndiswrapper. I think 
it's an interesting (and difficult) problem to solve if 4K-stacks gets in.

LWN has a piece on the possible options, but I suppose you could use the 
argument that forcibly breaking ndiswrapper will spur new driver development 
(but if you look at vendors like Broadcom, they have seem consistently 
unwilling to do this).

http://lwn.net/Articles/150580/

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> LWN has a piece on the possible options, but I suppose you could use the 
> argument that forcibly breaking ndiswrapper will spur new driver development 
> (but if you look at vendors like Broadcom, they have seem consistently 
> unwilling to do this).

there now is a specification for the broadcom wireless, and a driver is
being written right now to that specification; and it seems to be
getting along quite well (it's not ready for primetime use yet but at
least they can send and receive stuff, which is probably the hardest
part)

Re: [2.6 patch] i386: always use 4k stacks

[Alistair John Strachan]

On Monday 14 November 2005 18:29, Arjan van de Ven wrote:
> > LWN has a piece on the possible options, but I suppose you could use the
> > argument that forcibly breaking ndiswrapper will spur new driver
> > development (but if you look at vendors like Broadcom, they have seem
> > consistently unwilling to do this).
>
> there now is a specification for the broadcom wireless, and a driver is
> being written right now to that specification; and it seems to be
> getting along quite well (it's not ready for primetime use yet but at
> least they can send and receive stuff, which is probably the hardest
> part)

Great news. Perhaps all is not lost. This seems to be a leading chip for 
laptop wireless, which is an especially contentious issue (since users cannot 
swap it out as easily due to BIOS locks).

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: [2.6 patch] i386: always use 4k stacks

[Linus Torvalds]

On Mon, 14 Nov 2005, Arjan van de Ven wrote:
> 
> there now is a specification for the broadcom wireless, and a driver is
> being written right now to that specification; and it seems to be
> getting along quite well (it's not ready for primetime use yet but at
> least they can send and receive stuff, which is probably the hardest
> part)

Goodie. With Broadcom and Intel on-board, we should have most of the 
market covered in wireless, and ndiswrappers really should be less of an 
argument (it was never an argument for me personally, but for others..). 

		Linus

Re: [2.6 patch] i386: always use 4k stacks

[Michael Buesch]

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

On Monday 14 November 2005 20:17, you wrote:
> 
> On Mon, 14 Nov 2005, Arjan van de Ven wrote:
> > 
> > there now is a specification for the broadcom wireless, and a driver is
> > being written right now to that specification; and it seems to be
> > getting along quite well (it's not ready for primetime use yet but at
> > least they can send and receive stuff, which is probably the hardest
> > part)
> 
> Goodie. With Broadcom and Intel on-board, we should have most of the 
> market covered in wireless, and ndiswrappers really should be less of an 
> argument (it was never an argument for me personally, but for others..). 

I really hope we get this thing usable in a few weeks.
Looks good so far... .

However, I did not test the broadcom driver on 4k-stacks,
as I only have a G4 with a broadcom card. ;) But I do not expect any problems.

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] i386: always use 4k stacks

[Rafael J. Wysocki]

Hi,

On Monday, 14 of November 2005 20:28, Michael Buesch wrote:
> On Monday 14 November 2005 20:17, you wrote:
> > 
> > On Mon, 14 Nov 2005, Arjan van de Ven wrote:
> > > 
> > > there now is a specification for the broadcom wireless, and a driver is
> > > being written right now to that specification; and it seems to be
> > > getting along quite well (it's not ready for primetime use yet but at
> > > least they can send and receive stuff, which is probably the hardest
> > > part)
> > 
> > Goodie. With Broadcom and Intel on-board, we should have most of the 
> > market covered in wireless, and ndiswrappers really should be less of an 
> > argument (it was never an argument for me personally, but for others..). 
> 
> I really hope we get this thing usable in a few weeks.
> Looks good so far... .

Great!

> However, I did not test the broadcom driver on 4k-stacks,
> as I only have a G4 with a broadcom card. ;) But I do not expect any problems.

If you want someone to test it on x86-64, I think I can do that.

Greetings,
Rafael

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Llu, 2005-11-14 at 18:02 +0000, Alistair John Strachan wrote:
> > If we spent our entire lives waiting for people to fix code nothing
> > would ever happen. Removing 8K stacks is a good thing to do for many
> > reasons. The ndis wrapper people have known it is coming for a long
> > time, and if it has a lot of users I'm sure someone in that community
> > will take the time to make patches.
> 
> I honestly don't know if this is the case, but is it conceivable that no patch 
> could be written to resolve this, because the Windows drivers themselves only 
> respect Windows stack limits (which are presumably still 8K?).

Both systems are (subject to memory limits) turing complete, so it is
definitely possible 8) The kernel itself switches stacks on an IRQ with
the 4K stack so you only have to worry about switching your kernel stack
not about taking interrupts on it and confusion that may cause.

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

Could someone either list or post a link to someplace that lists
all the advantages of 4K stacks? 

-Alex


I code, therefore I am


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [2.6 patch] i386: always use 4k stacks

[Cal Peake]

On Tue, 15 Nov 2005, Alex Davis wrote:

> Could someone either list or post a link to someplace that lists
> all the advantages of 4K stacks? 

See the help text for the option under the kernel configurator...

or <http://lwn.net/Articles/84583/>

To summarize: it allows for more processes/threads (each process/thread 
requires a kernel stack) and it makes it easier for the VM subsystem to 
allocate larger than order 0 (4k) memory segments (i.e. it will be easier 
to find contiguous free blocks).

HTH,
-cp

-- 
Phishing, pharming; n.: Ways to obtain phood. -- The Devil's Infosec Dictionary

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Tue, 2005-11-15 at 16:50 -0800, Alex Davis wrote:
> Could someone either list or post a link to someplace that lists
> all the advantages of 4K stacks? 

* less kernel memory (eg lowmem) used for a thread 
   - allows more threads on the same system (java!)
   - increases performance in high-thread systems because more memory
     is available for disk cache etc
* thread stacks are now order 0 not order 1
   - order 0 is easy for the VM, order > 0 is harder (increasingly so
     the higher the order; so the 16Kb/32Kb request is just really
     wrong). For order > 0, fragmentation becomes an issue (just look
     at the entire fragmentation debate from a few weeks ago how bad
     a problem fragmentation can be). Thread stacks are just about the
     last remaining "big" user of order > 0 allocations normally.
     (eg excluding init/setup code)
   - order 0 allocations come from a per cpu "quicklist" of pages, 
     while order>0 allocations need to go to a global allocator pool.
     "global" means "cache line bounces" and "cpu scalability problem".
* less CPU cache footprint due to interrupt stacks
   - interrupt stacks are per cpu now instead of borrowing the per
     thread stack space; this both has less impact on the caches, and
     has more cache hits; the per cpu stack will be in cache more than
     the previously scattered bits and pieces
* more stack space is available for interrupts compared to 2.4 kernels
   - in 2.4 kernels only 2Kb was available for interrupt context (to
     keep 4K available for user context). With complex softirqs such as
     PPP and firewall rules and nested interrupts this wasn't always
     enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
     2Kb extra available there compared to 2.4 and arguably some of that
     extra is for interrupts.

Re: [2.6 patch] i386: always use 4k stacks

[Oliver Neukum]

Am Mittwoch, 16. November 2005 09:03 schrieb Arjan van de Ven:
> * less CPU cache footprint due to interrupt stacks
>    - interrupt stacks are per cpu now instead of borrowing the per
>      thread stack space; this both has less impact on the caches, and
>      has more cache hits; the per cpu stack will be in cache more than
>      the previously scattered bits and pieces
> * more stack space is available for interrupts compared to 2.4 kernels
>    - in 2.4 kernels only 2Kb was available for interrupt context (to
>      keep 4K available for user context). With complex softirqs such as
>      PPP and firewall rules and nested interrupts this wasn't always
>      enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
>      2Kb extra available there compared to 2.4 and arguably some of that
>      extra is for interrupts.

This is due to having interrupt stacks. Is there any reason not to have
8K task stacks and per CPU interrupt stacks?

	Regards
		Oliver

Re: [2.6 patch] i386: always use 4k stacks

[Ingo Molnar]

* Oliver Neukum <oliver@neukum.org> wrote:

> Am Mittwoch, 16. November 2005 09:03 schrieb Arjan van de Ven:
> > * less CPU cache footprint due to interrupt stacks
> >    - interrupt stacks are per cpu now instead of borrowing the per
> >      thread stack space; this both has less impact on the caches, and
> >      has more cache hits; the per cpu stack will be in cache more than
> >      the previously scattered bits and pieces
> > * more stack space is available for interrupts compared to 2.4 kernels
> >    - in 2.4 kernels only 2Kb was available for interrupt context (to
> >      keep 4K available for user context). With complex softirqs such as
> >      PPP and firewall rules and nested interrupts this wasn't always
> >      enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> >      2Kb extra available there compared to 2.4 and arguably some of that
> >      extra is for interrupts.
> 
> This is due to having interrupt stacks. Is there any reason not to 
> have 8K task stacks and per CPU interrupt stacks?

yes, all the other arguments you snipped :) Arjan wrote 4K+4K stacks for 
Fedora almost 2 years ago, and the patch has a good track record. Here's 
some more background info about 4K+4K stacks:

 http://lwn.net/Articles/84583/
 http://lwn.net/Articles/150580/
 http://lwn.net/Articles/160138/

	Ingo

Re: [2.6 patch] i386: always use 4k stacks

[Wed, 16 Nov 2005 11:18:12 +0100]

El Wed, 16 Nov 2005 09:03:32 +0100,
Arjan van de Ven <arjan@infradead.org> escribió:


> * more stack space is available for interrupts compared to 2.4 kernels
>    - in 2.4 kernels only 2Kb was available for interrupt context (to
>      keep 4K available for user context). With complex softirqs such as
>      PPP and firewall rules and nested interrupts this wasn't always
>      enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
>      2Kb extra available there compared to 2.4 and arguably some of that
>      extra is for interrupts.


I would like to contribute that listing with two non-technical reasons
more:

 * Encourages good code. Due to the 4 Kb stacks patch several parts of
	the kernel have gone on diet, improving the quality of the code
	(see ndiswrapper, ndis drivers can overflow the stack even with
	8KB stacks, the 4KB patch will force them to develop a _real_
	safe solution for that, improving the quality of ndiswrapper).

 * Some distros are enabling 4KB (fedora), other distros aren't, so
	having a single stack size option will make 3rd party modules
	distribution easier (some propietary drivers may not be caring
	about making their drivers work with 4Kb stacks due to the lack
	of uniformity)

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Wed, 2005-11-16 at 11:18 +0100, Wed, 16 Nov 2005 11:18:12 +0100
wrote:
> El Wed, 16 Nov 2005 09:03:32 +0100,
> Arjan van de Ven <arjan@infradead.org> escribió:
> 
> 
> > * more stack space is available for interrupts compared to 2.4 kernels
> >    - in 2.4 kernels only 2Kb was available for interrupt context (to
> >      keep 4K available for user context). With complex softirqs such as
> >      PPP and firewall rules and nested interrupts this wasn't always
> >      enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> >      2Kb extra available there compared to 2.4 and arguably some of that
> >      extra is for interrupts.
> 
> 
> I would like to contribute that listing with two non-technical reasons
> more:
> 
>  * Encourages good code. Due to the 4 Kb stacks patch several parts of
> 	the kernel have gone on diet, improving the quality of the code

this argument I agree with. especially since 64 bit platforms have a
higher stack footprint by nature (bigger call frames and more to store
on the stack) and if x86 allows stackbloat, the other architectures get
in trouble and are going to need really large stacks.

>  * Some distros are enabling 4KB (fedora), other distros aren't, so
> 	having a single stack size option will make 3rd party modules
> 	distribution easier (some propietary drivers may not be caring
> 	about making their drivers work with 4Kb stacks due to the lack
> 	of uniformity)

this I don't see as a reason; illegal drivers should never be a reason
to clutter our kernel one way or the other. And for GPL 3rd party
drivers the problem isn't there realistically. If they were reliable in
2.4, they're reliable with 2.6+4K stacks. If they're not then they need
to be fixed (eg your previous point).

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

Arjan van de Ven <arjan@infradead.org> writes:


> > I would like to contribute that listing with two non-technical reasons
> > more:
> > 
> >  * Encourages good code. Due to the 4 Kb stacks patch several parts of
> > 	the kernel have gone on diet, improving the quality of the code
> 
> this argument I agree with. especially since 64 bit platforms have a
> higher stack footprint by nature (bigger call frames and more to store
> on the stack) and if x86 allows stackbloat, the other architectures get
> in trouble and are going to need really large stacks.

I think it's in general risky. It's like balancing without a safety
net.  Might be a nice hobby, but for real production you want a safety
net.  That's simple because there are likely some code paths through
the code that need more stack space and that are rarely hit (and
cannot be easily found by static analysis, e.g. if they involve
indirect pointers or particularly complex configuration setups). With
very tight stack space you're much nearer a crash in extreme
situations than otherwise.

So I think it's a bad idea to change this.

-Andi (who prefers to have safety nets)

Re: [2.6 patch] i386: always use 4k stacks

[Jörn Engel]

On Wed, 16 November 2005 13:57:36 +0100, Andi Kleen wrote:
> 
> I think it's in general risky. It's like balancing without a safety
> net.  Might be a nice hobby, but for real production you want a safety
> net.  That's simple because there are likely some code paths through
> the code that need more stack space and that are rarely hit (and
> cannot be easily found by static analysis, e.g. if they involve
> indirect pointers or particularly complex configuration setups).

It isn't that hard to find such places.  Trouble is that you find so
many of them and it takes quite a while to go through them all.  Years
is a good unit for "quite a while".

Jörn

-- 
With a PC, I always felt limited by the software available. On Unix, 
I am limited only by my knowledge.
-- Peter J. Schoenster

Re: [2.6 patch] i386: always use 4k stacks

[jmerkey]

Jörn Engel wrote:

>On Wed, 16 November 2005 13:57:36 +0100, Andi Kleen wrote:
>  
>
>>I think it's in general risky. It's like balancing without a safety
>>net.  Might be a nice hobby, but for real production you want a safety
>>net.  That's simple because there are likely some code paths through
>>the code that need more stack space and that are rarely hit (and
>>cannot be easily found by static analysis, e.g. if they involve
>>indirect pointers or particularly complex configuration setups).
>>    
>>
>
>It isn't that hard to find such places.  Trouble is that you find so
>many of them and it takes quite a while to go through them all.  Years
>is a good unit for "quite a while".
>
>Jörn
>
>  
>
Map a blank ro page beneath the address range when stack memory is 
mapped is trap on page faults to the page when folks go off the end of 
th e stack.

Easy to find.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Jörn Engel]

On Wed, 16 November 2005 07:42:06 -0700, jmerkey wrote:
> >
> Map a blank ro page beneath the address range when stack memory is 
> mapped is trap on page faults to the page when folks go off the end of 
> th e stack.

You forgot the part with the testcase that will trigger every single
possible stack overflow.

> Easy to find.

Jörn

-- 
Sometimes, asking the right question is already the answer.
-- Unknown

Re: [2.6 patch] i386: always use 4k stacks

[Oliver Neukum]

Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> Map a blank ro page beneath the address range when stack memory is 
> mapped is trap on page faults to the page when folks go off the end of 
> th e stack.
> 
> Easy to find.

Provided you can easily trigger it. I don't see how that is a given.

	Regards
		Oliver

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > Map a blank ro page beneath the address range when stack memory is 
> > mapped is trap on page faults to the page when folks go off the end of 
> > th e stack.
> > 
> > Easy to find.
> 
> Provided you can easily trigger it. I don't see how that is a given.

the same is true for a unified 8k stack or for the 4k/4k split though.
Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
the other side)

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

On Wednesday 16 November 2005 16:38, Arjan van de Ven wrote:
> On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> > Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > > Map a blank ro page beneath the address range when stack memory is 
> > > mapped is trap on page faults to the page when folks go off the end of 
> > > th e stack.
> > > 
> > > Easy to find.
> > 
> > Provided you can easily trigger it. I don't see how that is a given.
> 
> the same is true for a unified 8k stack or for the 4k/4k split though.
> Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
> the other side)

I was always in favour of 8K process stacks + irq stacks. Works great on x86-64.

-Andi

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Wed, Nov 16, 2005 at 05:10:04PM +0100, Andi Kleen wrote:
> On Wednesday 16 November 2005 16:38, Arjan van de Ven wrote:
> > On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> > > Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > > > Map a blank ro page beneath the address range when stack memory is 
> > > > mapped is trap on page faults to the page when folks go off the end of 
> > > > th e stack.
> > > > 
> > > > Easy to find.
> > > 
> > > Provided you can easily trigger it. I don't see how that is a given.
> > 
> > the same is true for a unified 8k stack or for the 4k/4k split though.
> > Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
> > the other side)
> 
> I was always in favour of 8K process stacks + irq stacks. Works great on x86-64.

Jörn did some analysis regarding possible call paths > 3k.

Our goal is to achieve a stack usage < 3k with a safety margin of 1k.

The problem is similar no matter whether you have 4k or 8k stacks, but 
with 4k stacks you have the additional benefits of order 0 allocations 
and less memory usage.

> -Andi

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] i386: always use 4k stacks

[Benjamin LaHaise]

On Wed, Nov 16, 2005 at 07:45:08PM +0100, Adrian Bunk wrote:
> The problem is similar no matter whether you have 4k or 8k stacks, but 
> with 4k stacks you have the additional benefits of order 0 allocations 
> and less memory usage.

We could implement a stack guard page for the transition period, so that 
any stack overflows would end up generating a fault.  That's easy enough 
to do by using vmalloc().

		-ben

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

On Wednesday 16 November 2005 20:03, Benjamin LaHaise wrote:
> On Wed, Nov 16, 2005 at 07:45:08PM +0100, Adrian Bunk wrote:
> > The problem is similar no matter whether you have 4k or 8k stacks, but 
> > with 4k stacks you have the additional benefits of order 0 allocations 
> > and less memory usage.
> 
> We could implement a stack guard page for the transition period, so that 
> any stack overflows would end up generating a fault.  That's easy enough 
> to do by using vmalloc()

And would add considerable overhead in TLB flushes and locking ...

-Andi

Re: [2.6 patch] i386: always use 4k stacks

[Wed, 16 Nov 2005 21:46:05 +0100]

El Wed, 16 Nov 2005 14:03:34 -0500,
Benjamin LaHaise <bcrl@kvack.org> escribió:

> We could implement a stack guard page for the transition period, so that 

CONFIG_DEBUG_STACKOVERFLOW doesn't do that but it looks useful too.

Does CONFIG_DEBUG_STACKOVERFLOW harm performance a lot? (doesn't 
look like that for a newbie's eye)

Re: [2.6 patch] i386: always use 4k stacks

[Andi Kleen]

On Wednesday 16 November 2005 21:46, Wed, 16 Nov 2005 21:46:05 +0100 wrote:
> El Wed, 16 Nov 2005 14:03:34 -0500,
> Benjamin LaHaise <bcrl@kvack.org> escribió:
> 
> > We could implement a stack guard page for the transition period, so that 
> 
> CONFIG_DEBUG_STACKOVERFLOW doesn't do that but it looks useful too.
> 
> Does CONFIG_DEBUG_STACKOVERFLOW harm performance a lot? (doesn't 
> look like that for a newbie's eye)

No, it's very cheap. In fact it could be probably enabled by default.

-Andi

P.S.: Can you please chose a less irritating realname?

 

Re: [2.6 patch] i386: always use 4k stacks

[Jörn Engel]

On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
> 
> Jörn did some analysis regarding possible call paths > 3k.

And most of them have been changed since.  Zlib remains high on the
list, but those paths are from /lib/inflate.c, during bootup.

What remains to be analysed is the recursions.  If someone seriously
wants to work on those, I can respin the tests.  The process is not
fully automated, so it will take me a weekend (and this weekend is
scheduled for a party).

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories

Re: [2.6 patch] i386: always use 4k stacks

[Jeffrey V. Merkey]

Jörn Engel wrote:

>On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
>  
>
>>Jörn did some analysis regarding possible call paths > 3k.
>>    
>>
>
>And most of them have been changed since.  Zlib remains high on the
>list, but those paths are from /lib/inflate.c, during bootup.
>
>What remains to be analysed is the recursions.  If someone seriously
>wants to work on those, I can respin the tests.  The process is not
>fully automated, so it will take me a weekend (and this weekend is
>scheduled for a party).
>
>Jörn
>
>  
>
The SCSI layer needs to be checked.  I reproduced another crash on today 
on an older Niksun box running off the end of the stack.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Jeffrey V. Merkey]

Jeffrey V. Merkey wrote:

> Jörn Engel wrote:
>
>> On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
>>  
>>
>>> Jörn did some analysis regarding possible call paths > 3k.
>>>   
>>
>>
>> And most of them have been changed since.  Zlib remains high on the
>> list, but those paths are from /lib/inflate.c, during bootup.
>>
>> What remains to be analysed is the recursions.  If someone seriously
>> wants to work on those, I can respin the tests.  The process is not
>> fully automated, so it will take me a weekend (and this weekend is
>> scheduled for a party).
>>
>> Jörn
>>
>>  
>>
> The SCSI layer needs to be checked.  I reproduced another crash on 
> today on an older Niksun box running off the end of the stack.
>
> Jeff
>
>
It's somewhere in the scanning code.  There's a case where it runs off 
the end of the stack.  Check the compaq drivers for SATA as well, they 
also crash in a similiar place during bus scan.  Both occurred during 
bootup, so I wasn't able to get a log of the particulars.  Should be 
easy to reproduce.  Compaq Presario 2200.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Jörn Engel]

On Wed, 16 November 2005 15:54:27 -0700, Jeffrey V. Merkey wrote:
> Jeffrey V. Merkey wrote:
> >>
> >The SCSI layer needs to be checked.  I reproduced another crash on 
> >today on an older Niksun box running off the end of the stack.
> >
> It's somewhere in the scanning code.  There's a case where it runs off 
> the end of the stack.  Check the compaq drivers for SATA as well, they 
> also crash in a similiar place during bus scan.  Both occurred during 
> bootup, so I wasn't able to get a log of the particulars.  Should be 
> easy to reproduce.  Compaq Presario 2200.

Do you have a backtrace for these?  Real-life problem tend to generate
more attention than theoretical results based on code checkers.

Jörn

-- 
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle

Re: [2.6 patch] i386: always use 4k stacks

[Jeff V. Merkey]

Jörn Engel wrote:

>On Wed, 16 November 2005 15:54:27 -0700, Jeffrey V. Merkey wrote:
>  
>
>>Jeffrey V. Merkey wrote:
>>    
>>
>>>The SCSI layer needs to be checked.  I reproduced another crash on 
>>>today on an older Niksun box running off the end of the stack.
>>>
>>>      
>>>
>>It's somewhere in the scanning code.  There's a case where it runs off 
>>the end of the stack.  Check the compaq drivers for SATA as well, they 
>>also crash in a similiar place during bus scan.  Both occurred during 
>>bootup, so I wasn't able to get a log of the particulars.  Should be 
>>easy to reproduce.  Compaq Presario 2200.
>>    
>>
>
>Do you have a backtrace for these?  Real-life problem tend to generate
>more attention than theoretical results based on code checkers.
>
>Jörn
>
>  
>
I'll try to get one tonight ad post to the list.

Jeff

Re: [2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

On Wed, Nov 16, 2005 at 03:54:27PM -0700, Jeffrey V. Merkey wrote:
> > 
> >The SCSI layer needs to be checked.  I reproduced another crash on 
> >today on an older Niksun box running off the end of the stack.
> >
> >Jeff
> >
> >
> It's somewhere in the scanning code.  There's a case where it runs off 
> the end of the stack.  Check the compaq drivers for SATA as well, they 
> also crash in a similiar place during bus scan.  Both occurred during 
> bootup, so I wasn't able to get a log of the particulars.  Should be 
> easy to reproduce.  Compaq Presario 2200.

Are you using completely unmodified ftp.kernel.org kernels?

Which version?

If it occurs during bootup, you should see the error displayed.
Please use a digital camera to photograph the error and send a linkt ot 
the photo.

> Jeff

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] i386: always use 4k stacks

[Jeff V. Merkey]

Adrian Bunk wrote:

>On Wed, Nov 16, 2005 at 03:54:27PM -0700, Jeffrey V. Merkey wrote:
>  
>
>>>The SCSI layer needs to be checked.  I reproduced another crash on 
>>>today on an older Niksun box running off the end of the stack.
>>>
>>>Jeff
>>>
>>>
>>>      
>>>
>>It's somewhere in the scanning code.  There's a case where it runs off 
>>the end of the stack.  Check the compaq drivers for SATA as well, they 
>>also crash in a similiar place during bus scan.  Both occurred during 
>>bootup, so I wasn't able to get a log of the particulars.  Should be 
>>easy to reproduce.  Compaq Presario 2200.
>>    
>>
>
>Are you using completely unmodified ftp.kernel.org kernels?.
>  
>

Yes.

>Which version?
>
>  
>
2.6.14

>If it occurs during bootup, you should see the error displayed.
>Please use a digital camera to photograph the error and send a linkt ot 
>the photo.
>
>  
>
The error is a stack trace rolling off the screen with a list of 
functions -- right before it reboots.

Jeff

>>Jeff
>>    
>>
>
>cu
>Adrian
>
>  
>

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Alan Cox wrote:

> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.

I believe I mentioned it before. ndiswrapper itself has been 4k stacks ready
for quite sometime. It is Windows drivers that need more than 4k stacks
(although Windows uses 12k stacks, I don't know of any Windows driver
requiring more than 8k stacks). One or two Windows drivers work with
ndiswrapper and 4k stacks, Broadcom for example.

If this 4k stack patch makes into mainstream, I am wondering what options,
other than maintaining a patch to back this patch, are available. The last
time this issue came up some people suggested pushing ndiswrapper into user
space. However, AFAIK this is non-trivial; I looked into FUSD
http://www.circlemud.org/~jelson/software/fusd/ which doesn't support
network drivers and seems to be not active in the recent past.

Any suggestions on how ndiswrapper can live with this patch would be greatly
appreciated.

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Olivier Galibert]

On Mon, Nov 14, 2005 at 01:29:54PM -0500, Giridhar Pemmasani wrote:
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.

Couldn't ndiswrapper have its own private stack to switch to when
calling the windows driver, or are there still things hanging off the
end of the stack area?

  OG.

Re: [2.6 patch] i386: always use 4k stacks

[Benjamin LaHaise]

On Mon, Nov 14, 2005 at 08:00:07PM +0100, Olivier Galibert wrote:
> Couldn't ndiswrapper have its own private stack to switch to when
> calling the windows driver, or are there still things hanging off the
> end of the stack area?

It's possible, but would need a change to how the kernel finds the thread 
local data (which is currently done by masking off the stack pointer).  
There are certainly a few ways of doing this, like using tr to find out 
which cpu we're on and then indexing into the thread info state.

		-ben
-- 
"Time is what keeps everything from happening all at once." -- John Wheeler

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

Benjamin LaHaise wrote:

> On Mon, Nov 14, 2005 at 08:00:07PM +0100, Olivier Galibert wrote:
>> Couldn't ndiswrapper have its own private stack to switch to when
>> calling the windows driver, or are there still things hanging off the
>> end of the stack area?

This has been discussed sometime back. Search for "ndiswrapper" on lkml.
See, e.g.,
http://marc.theaimsgroup.com/?l=linux-kernel&m=112602638406796&w=2

> It's possible, but would need a change to how the kernel finds the thread
> local data (which is currently done by masking off the stack pointer).
> There are certainly a few ways of doing this, like using tr to find out
> which cpu we're on and then indexing into the thread info state.

If any such alternate ways are used instead of relying on stack pointer, we
could have implemented private stacks for threads in ndiswrapper (and
driverloader).

Giri

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Llu, 2005-11-14 at 13:29 -0500, Giridhar Pemmasani wrote:
> If this 4k stack patch makes into mainstream, I am wondering what options,
> other than maintaining a patch to back this patch, are available. The last
> time this issue came up some people suggested pushing ndiswrapper into user
> space. However, AFAIK this is non-trivial; I looked into FUSD
> http://www.circlemud.org/~jelson/software/fusd/ which doesn't support
> network drivers and seems to be not active in the recent past.
> 
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.


Switch stack before calling the Windows bits. If we take an IRQ then the
kernel will itself switch to its own IRQ stack for the IRQ handling. I
don't think there is much more required.

Re: [2.6 patch] i386: always use 4k stacks

[Giridhar Pemmasani]

On Mon, 14 Nov 2005 22:33:57 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> said:

  Alan> Switch stack before calling the Windows bits. If we take an IRQ then
  Alan> the kernel will itself switch to its own IRQ stack for the IRQ
  Alan> handling. I don't think there is much more required.

Shouldn't I have to prevent scheduler from changing the tasks when executing
Windows code? Otherwise, kernel gets wrong current thread information,
which is based on stack pointer. This is the stumbling block for implementing
private stacks.

Thanks,
Giri

Re: [2.6 patch] i386: always use 4k stacks

[Paulo Marques]

Giridhar Pemmasani wrote:
> Alan Cox wrote:
> 
>>reasons. The ndis wrapper people have known it is coming for a long
>>time, and if it has a lot of users I'm sure someone in that community
>>will take the time to make patches.
> 
>[...]
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.

One idea that has not yet been suggested, is to use a x86 emulator to 
run the driver code.

I did some development a while ago, to reduce the size a x86 emulator to 
run VGA BIOS functions. If an emulator like this would make it to the 
kernel it could also be used to change video modes even using the VESA 
driver, suspend/resume the VGA using the VGA own code, etc.

The final size of the emulator was a little over 30k, but there was 
still room for even more reductions.


The advantages:

  - the driver runs in a complete sandbox

  - support for running NDIS drivers in multiple architectures (not just 
x86)

  - the emulator could be shared amongst more kernel subsystems in need 
of an emulator (VESA, for instance)


Disadvantages:

  - increase in kernel code size (about 30k)

  - decrease in driver code execution speed


I'm not really advocating for this, just wanted to make sure people 
would be aware of all the solutions available before committing to any 
approach.

-- 
Paulo Marques - www.grupopie.com

The rule is perfect: in all matters of opinion our
adversaries are insane.
Mark Twain

Re: [2.6 patch] i386: always use 4k stacks

[Alex Davis]

That doesn't answer my question. I want to know what __problems__
are caused by allowing the __choice__ of stack sizes.

-Alex


--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> If we spent our entire lives waiting for people to fix code nothing
> would ever happen. Removing 8K stacks is a good thing to do for many
> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.
> 
> 


I code, therefore I am


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

[2.6 patch] i386: always use 4k stacks

[Adrian Bunk]

It seems most problems with 4k stacks are already resolved.

I'd like to see this patch to always use 4k stacks in -mm now for 
finding any remaining problems before submitting this patch for 2.6.16.


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

---

 arch/i386/Kconfig.debug        |   10 ----------
 arch/i386/kernel/irq.c         |   10 ----------
 include/asm-i386/irq.h         |   11 +++--------
 include/asm-i386/module.h      |    8 +-------
 include/asm-i386/thread_info.h |    6 +-----
 5 files changed, 5 insertions(+), 40 deletions(-)

--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old	2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug	2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
 	  portion of the kernel code won't be covered by a 2MB TLB anymore.
 	  If in doubt, say "N".
 
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	depends on DEBUG_KERNEL
-	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.14-mm2-full/include/asm-i386/irq.h.old	2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h	2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
 # define ARCH_HAS_NMI_WATCHDOG		/* See include/linux/nmi.h */
 #endif
 
-#ifdef CONFIG_4KSTACKS
-  extern void irq_ctx_init(int cpu);
-  extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
 
 #ifdef CONFIG_IRQBALANCE
 extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old	2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h	2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
 #endif
 
 #define PREEMPT_ACTIVE		0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE            (4096)
-#else
-#define THREAD_SIZE		(8192)
-#endif
+#define THREAD_SIZE		(4096)
 
 #define STACK_WARN             (THREAD_SIZE/8)
 /*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old	2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h	2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
 #define MODULE_REGPARM ""
 #endif
 
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */
--- linux-2.6.14-mm2-full/arch/i386/kernel/irq.c.old	2005-11-14 01:32:56.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/kernel/irq.c	2005-11-14 01:33:28.000000000 +0100
@@ -33,7 +33,6 @@
 }
 #endif
 
-#ifdef CONFIG_4KSTACKS
 /*
  * per-CPU IRQ handling contexts (thread information and stack)
  */
@@ -44,7 +43,6 @@
 
 static union irq_ctx *hardirq_ctx[NR_CPUS];
 static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
 
 /*
  * do_IRQ handles all normal device IRQ's (the special
@@ -58,10 +56,8 @@
 #ifdef CONFIG_DEBUG_PREEMPT
 	u32 count = preempt_count() & PREEMPT_MASK;
 #endif
-#ifdef CONFIG_4KSTACKS
 	union irq_ctx *curctx, *irqctx;
 	u32 *isp;
-#endif
 
 	irq_enter();
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -79,8 +75,6 @@
 	}
 #endif
 
-#ifdef CONFIG_4KSTACKS
-
 	curctx = (union irq_ctx *) current_thread_info();
 	irqctx = hardirq_ctx[smp_processor_id()];
 
@@ -118,7 +112,6 @@
 		irqctx->tinfo.preempt_count -= count;
 #endif
 	} else
-#endif
 		__do_IRQ(irq, regs);
 
 	irq_exit();
@@ -128,8 +121,6 @@
 	return 1;
 }
 
-#ifdef CONFIG_4KSTACKS
-
 /*
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
@@ -228,7 +219,6 @@
 }
 
 EXPORT_SYMBOL(do_softirq);
-#endif
 
 /*
  * Interrupt statistics:

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Mon, 2005-11-14 at 03:11 +0100, Adrian Bunk wrote:
> It seems most problems with 4k stacks are already resolved.
> 
> I'd like to see this patch to always use 4k stacks in -mm now for 
> finding any remaining problems before submitting this patch for
> 2.6.16.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Acked-by: Arjan van de Ven <arjan@infradead.org>
> 

Re: [2.6 patch] i386: always use 4k stacks

[Pierre Ossman]

Adrian Bunk wrote:
> It seems most problems with 4k stacks are already resolved.
> 
> I'd like to see this patch to always use 4k stacks in -mm now for 
> finding any remaining problems before submitting this patch for 2.6.16.
> 
> 

Has the block layer been remade to a serial approach? Last time I 
checked you could exhaust the stack fairly easy by layering a couple of 
block subsystems on each other (usb+scsi+raid+lvm+xfs+nfs to make things 
as horrible as possible).

Rgds
Pierre

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> Adrian Bunk wrote:
> > It seems most problems with 4k stacks are already resolved.
> > 
> > I'd like to see this patch to always use 4k stacks in -mm now for 
> > finding any remaining problems before submitting this patch for 2.6.16.
> > 
> > 
> 
> Has the block layer been remade to a serial approach? 

yes.

Re: [2.6 patch] i386: always use 4k stacks

[Pierre Ossman]

Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
>   
>>
>> Has the block layer been remade to a serial approach? 
>>     
>
> yes.
>
>   

Great. Then please excuse my uninformed objections. :)

Rgds
Pierre

Re: [2.6 patch] i386: always use 4k stacks

[Jens Axboe]

On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > Adrian Bunk wrote:
> > > It seems most problems with 4k stacks are already resolved.
> > > 
> > > I'd like to see this patch to always use 4k stacks in -mm now for 
> > > finding any remaining problems before submitting this patch for 2.6.16.
> > > 
> > > 
> > 
> > Has the block layer been remade to a serial approach? 
> 
> yes.

Not in mainline it hasn't.

Are there any recent benchmarks of 4kb vs 8kb stacks? Is anyone shipping
4kb stack kernels?

-- 
Jens Axboe

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Mon, 2005-11-14 at 12:11 +0100, Jens Axboe wrote:
> On Mon, Nov 14 2005, Arjan van de Ven wrote:
> > On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > > Adrian Bunk wrote:
> > > > It seems most problems with 4k stacks are already resolved.
> > > > 
> > > > I'd like to see this patch to always use 4k stacks in -mm now for 
> > > > finding any remaining problems before submitting this patch for 2.6.16.
> > > > 
> > > > 
> > > 
> > > Has the block layer been remade to a serial approach? 
> > 
> > yes.
> 
> Not in mainline it hasn't.

well the patch was for -mm ;)

> 
> Are there any recent benchmarks of 4kb vs 8kb stacks?

not sure; I do know that it very much helps java (many more threads
possible) and the VM (far less order 1 allocs). In addition the 4Kb
allocation can be satisfied with the per cpu list of free 4Kb pages,
while obviously an order 1 cannot and has to go global.

>  Is anyone shipping 4kb stack kernels?

Both Fedora and RHEL are shipping this for all 2.6 based versions (eg
FC2 and all later, RHEL4)

Re: [2.6 patch] i386: always use 4k stacks

[Jens Axboe]

On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 12:11 +0100, Jens Axboe wrote:
> > On Mon, Nov 14 2005, Arjan van de Ven wrote:
> > > On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > > > Adrian Bunk wrote:
> > > > > It seems most problems with 4k stacks are already resolved.
> > > > > 
> > > > > I'd like to see this patch to always use 4k stacks in -mm now for 
> > > > > finding any remaining problems before submitting this patch for 2.6.16.
> > > > > 
> > > > > 
> > > > 
> > > > Has the block layer been remade to a serial approach? 
> > > 
> > > yes.
> > 
> > Not in mainline it hasn't.
> 
> well the patch was for -mm ;)

ok :)

> > 
> > Are there any recent benchmarks of 4kb vs 8kb stacks?
> 
> not sure; I do know that it very much helps java (many more threads
> possible) and the VM (far less order 1 allocs). In addition the 4Kb
> allocation can be satisfied with the per cpu list of free 4Kb pages,
> while obviously an order 1 cannot and has to go global.

I realize it has nice advantages in theory, just wondering if anyone has
done a performance analysis of 4kb vs 8kb stacks lately (or at all?).

> >  Is anyone shipping 4kb stack kernels?
> 
> Both Fedora and RHEL are shipping this for all 2.6 based versions (eg
> FC2 and all later, RHEL4)

Cool, that's the kind of testing coverage I was hoping for.

-- 
Jens Axboe

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

On Mon, 2005-11-14 at 12:24 +0100, Jens Axboe wrote:
> > 
> > not sure; I do know that it very much helps java (many more threads
> > possible) and the VM (far less order 1 allocs). In addition the 4Kb
> > allocation can be satisfied with the per cpu list of free 4Kb pages,
> > while obviously an order 1 cannot and has to go global.
> 
> I realize it has nice advantages in theory, just wondering if anyone has
> done a performance analysis of 4kb vs 8kb stacks lately (or at all?).

I don't think at least anyone at RH has done any; the functionality gain
was already enough for us. One item I missed: in the many-thread cases,
you also save a lot of memory that can now be used for pagecache; 
this won't of course be visible in a microbenchmark but should help
system wide.

Also in the implementation I don't see any way 4Kb stacks could show up
in any benchmarks as negative; there are only 4 or 5 extra instructions
in any path, and afaics no cache downsides (in fact the same irq stack
memory is now reused for irqs instead of threadstack-du-jour, so less
footprint/hotter caches)

Re: [2.6 patch] i386: always use 4k stacks

[Jens Axboe]

On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 12:24 +0100, Jens Axboe wrote:
> > > 
> > > not sure; I do know that it very much helps java (many more threads
> > > possible) and the VM (far less order 1 allocs). In addition the 4Kb
> > > allocation can be satisfied with the per cpu list of free 4Kb pages,
> > > while obviously an order 1 cannot and has to go global.
> > 
> > I realize it has nice advantages in theory, just wondering if anyone has
> > done a performance analysis of 4kb vs 8kb stacks lately (or at all?).
> 
> I don't think at least anyone at RH has done any; the functionality gain
> was already enough for us. One item I missed: in the many-thread cases,
> you also save a lot of memory that can now be used for pagecache; 
> this won't of course be visible in a microbenchmark but should help
> system wide.
> 
> Also in the implementation I don't see any way 4Kb stacks could show up
> in any benchmarks as negative; there are only 4 or 5 extra instructions
> in any path, and afaics no cache downsides (in fact the same irq stack
> memory is now reused for irqs instead of threadstack-du-jour, so less
> footprint/hotter caches)

The only downside is the potential crashes due to overflowing the stack,
I'm not worried about 4kb stacks performing worse.

-- 
Jens Axboe

Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven]

> > 
> > Also in the implementation I don't see any way 4Kb stacks could show up
> > in any benchmarks as negative; there are only 4 or 5 extra instructions
> > in any path, and afaics no cache downsides (in fact the same irq stack
> > memory is now reused for irqs instead of threadstack-du-jour, so less
> > footprint/hotter caches)
> 
> The only downside is the potential crashes due to overflowing the stack,
> I'm not worried about 4kb stacks performing worse.
> 

First of all the 8Kb->4Kb change sounds like a big change, but 4Kb
really is 4Kb+4Kb (eg interrupt stacks). So the net reduction in
available stack for user context is a lot less (IRQ context need at
least 2Kb given that this is reentrant code wrt softirq processing),
probably in the order of 2Kb (compared to 8Kb 2.6 kernels) to 500 bytes
compared to 2.4 kernels (in 2.4 you lost 1.5 to the task struct on the
stack).

The experience with Fedora so far is exceptionally good; in early 2.6
there were some reports with XFS stacked on top of DM, but since then
XFS has gone on a stack diet... also the -mm patches to do non-recursive
IO submission will bury this (mostly theoretical) monster for good.

Re: [2.6 patch] i386: always use 4k stacks

[Pierre Ossman]

Arjan van de Ven wrote:
>
> The experience with Fedora so far is exceptionally good; in early 2.6
> there were some reports with XFS stacked on top of DM, but since then
> XFS has gone on a stack diet... also the -mm patches to do non-recursive
> IO submission will bury this (mostly theoretical) monster for good.
>
>   

Fedora with their 2.6.12 and raid+xfs+nfs still causes occasional 
problems for me. Haven't tried their 2.6.14. But until the block layer 
modifications are mainline I'm sticking with 8 KiB. My heart momentarily 
stops every time the file server decides to have a kernel panic, so 
better safe than sorry.

Rgds
Pierre

Re: [2.6 patch] i386: always use 4k stacks

[Olivier Galibert]

On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
> The experience with Fedora so far is exceptionally good; in early 2.6
> there were some reports with XFS stacked on top of DM, but since then
> XFS has gone on a stack diet... also the -mm patches to do non-recursive
> IO submission will bury this (mostly theoretical) monster for good.

Not theorical for iscsi though.  I guess net+block is a little too
much.

  OG.

Re: [2.6 patch] i386: always use 4k stacks

[Alan Cox]

On Llu, 2005-11-14 at 13:04 +0100, Olivier Galibert wrote:
> Not theorical for iscsi though.  I guess net+block is a little too
> much.

net + block fits for the simpler stuff at least (nbd, ataoe)

Re: [2.6 patch] i386: always use 4k stacks

[Mike Christie]

Olivier Galibert wrote:
> On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
> 
>>The experience with Fedora so far is exceptionally good; in early 2.6
>>there were some reports with XFS stacked on top of DM, but since then
>>XFS has gone on a stack diet... also the -mm patches to do non-recursive
>>IO submission will bury this (mostly theoretical) monster for good.
> 
> 
> Not theorical for iscsi though.  I guess net+block is a little too
> much.
> 

If you have stack problem with iscsi then you should post it to those 
lists or send me a pointer offlist. There were problems with iscsi and 
XFS but they should be fixed in mainline. The XFS + iscsi problems that 
have been reported have not been stack usage problems though.

Re: [2.6 patch] i386: always use 4k stacks

[Mike Christie]

Mike Christie wrote:
> Olivier Galibert wrote:
> 
>> On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
>>
>>> The experience with Fedora so far is exceptionally good; in early 2.6
>>> there were some reports with XFS stacked on top of DM, but since then
>>> XFS has gone on a stack diet... also the -mm patches to do non-recursive
>>> IO submission will bury this (mostly theoretical) monster for good.
>>
>>
>>
>> Not theorical for iscsi though.  I guess net+block is a little too
>> much.
>>
> 
> If you have stack problem with iscsi then you should post it to those 
> lists or send me a pointer offlist. There were problems with iscsi and 
> XFS but they should be fixed in mainline. The XFS + iscsi problems that 
> have been reported have not been stack usage problems though.
> 

I think to hit a iscsi stack problem you will have to have the scsi 
request_fn get called from __make_request (or one of the functions it 
calls like __elv_add_request which looks like it could call 
__generic_unplug_device). And then the iscsi queuecomamnd would have to 
hit the path that calls iscsi_data_xmit. Have you hit this?

Re: [2.6 patch] i386: always use 4k stacks

[Olivier Galibert]

On Mon, Nov 14, 2005 at 06:32:02PM -0600, Mike Christie wrote:
> If you have stack problem with iscsi then you should post it to those 
> lists or send me a pointer offlist. There were problems with iscsi and 
> XFS but they should be fixed in mainline. The XFS + iscsi problems that 
> have been reported have not been stack usage problems though.

That hasn't been very efficient last time.  In any case, on the latest
version I tried (0.4-408, I can't blow up the backup machine every
other day):

- iscsi-tape is incompatible with tg3 and works with e1000

- iscsi-disk blows after a random time in what seems to be a (irq?)
  stack explosion on x86 but not on x86-64 (which iirc has bigger
  stacks).  Seems to because the serial console blows too and only
  writes a handful of characters.

Filesystem is reiser3.

  OG.

Re: [2.6 patch] i386: always use 4k stacks

[Mike Christie]

Olivier Galibert wrote:
> On Mon, Nov 14, 2005 at 06:32:02PM -0600, Mike Christie wrote:
> 
>>If you have stack problem with iscsi then you should post it to those 
>>lists or send me a pointer offlist. There were problems with iscsi and 
>>XFS but they should be fixed in mainline. The XFS + iscsi problems that 
>>have been reported have not been stack usage problems though.
> 
> 
> That hasn't been very efficient last time.  In any case, on the latest
> version I tried (0.4-408, I can't blow up the backup machine every
> other day):
> 
> - iscsi-tape is incompatible with tg3 and works with e1000
> 
> - iscsi-disk blows after a random time in what seems to be a (irq?)
>   stack explosion on x86 but not on x86-64 (which iirc has bigger
>   stacks).  Seems to because the serial console blows too and only
>   writes a handful of characters.
> 

And these only occur with 4k stacks? Do you have the traces still?