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 [email protected]
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