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

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

 



On Fri, 16 Dec 2005, linux-os (Dick Johnson) wrote:

On Fri, 16 Dec 2005, Horst von Brand wrote:

linux-os \(Dick Johnson\) <[email protected]> wrote:

[...]

Throughout the past two years of 4k stack-wars, I never heard why
such a small stack was needed (not wanted, needed). It seems that
everybody "knows" that smaller is better and most everybody thinks
that one page in ix86 land is "optimum". However I don't think
anybody ever even tried to analyze what was better from a technical
perspective. Instead it's been analyzed as religious dogma, i.e.,
keep the stack small, it will prevent idiots from doing bad things.

OK, so here goes again...

The kernel stack has to be contiguous in /physical/ memory. Keep the
stack
/one/ page, that way you can always get a new stack when needed (==
each
fork(2) or clone(2)). If the stack is 2 (or more) pages, you'll have
to
find (or create) a multi-page free area, and (fragmentation being what
it
is, and Linux routinely running for months at a time) you are in a
whole
new world of pain.

The interrupt stack needs to be non-paged. Are you sure the user-stacks
need to be 'physical', non-paged too? If so, that's probably the
problem. All addresses accessed by the CPUs in the kernel are virtual
which means one needs some mapping anyway.

actually, the kernel always uses real addresses, userspace uses virtual addresses.

This came up recently with the page tables, Linus said that he was absolutly opposed to adding the complication and overhead of changine the kernel to user virtual addresses instead of real addresses for it's data structures. it would add an extra level of redirection to just about every memory access (which also means an additional load on the cache to store the mapping info to resolve this redirection). The performance hit for this would be considerable.

David Lang
-
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