lkml.org 
[lkml]   [2005]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [2.6 patch] i386: always use 4k stacks
Date

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/

\
 
 \ /
  Last update: 2005-12-19 17:26    [W:0.093 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site