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

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

 



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