lkml.org 
[lkml]   [2005]   [Dec]   [17]   [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 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





-
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-17 21:19    [W:0.129 / U:3.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site