Re: 4k stacks in 2.6

[Andrea Arcangeli]

On Thu, May 27, 2004 at 07:55:36AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 27 May 2004, Andrea Arcangeli wrote:
> >
> > On Thu, May 27, 2004 at 10:18:40AM -0400, Brian Gerst wrote:
> > > The problem on i386 (unlike x86-64) is that the thread_info struct sits 
> > > at the bottom of the stack and is referenced by masking bits off %esp. 
> > > So the stack size must be constant whether in process context or IRQ 
> > > context.
> > 
> > so what, that's a minor implementation detail, pda is a software thing.
> 
> "minor implementation detail"?
> 
> You need to get to the thread info _some_ way, and you need to get to it
> _fast_. There are really no sane alternatives. I certainly do not want to
> play games with segments.

If the page is "even" the thread_info is at the top of the stack. If the
page is "odd" the thread_info is at the bottom of the stack (or the
other way around depending what you mean with "odd" and "even").

the per-cpu irq stack will have the thread_info at both the top and the
bottom of the 8k naturally aligned order1 compound page. The regular
kernel stack will have it at the top or the bottom depending if it's odd
or even.

this should allow 8k irqstack and bh stack fine at in-cpu-core speed w/o
segments or similar.

The only downside is that itadds a branch to current_thread_info that
will have to check the 12th bitflag in the esp before doing andl, the
second downside is having to update two thread_info during irq, instead
of just one.

It would be probably better if the thread_info was just a pointer to a
"pda" instead of being the PDA itself so there are just two writes into
the kernel stack for every irq. In x86-64 this is much more natural
since the pda-pointer is in the cpu 64bit %gs register and that saves a
branch and defereference on the stack for every "current" invocation,
and two writes for every first-irq or first-bh. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/