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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux