On Tue, Oct 10, 2000 at 09:04:30AM +1100, Keith Owens wrote:
> On 9 Oct 2000 11:08:36 -0700,
> torvalds@transmeta.com (Linus Torvalds) wrote:
> >Note that there are alternative approaches. For example, you could make
> >the interrupt stack be in the same multi-page as the regular stack, and
> >switch them both at task-switch time - just allocate four pages instead
> >of two, and use "current = esp & ~16383" instead or something like that.
>
> Ouch. Too many places in the source have hard coded 8191 or 8192.
> Would you take a patch to replace all those hard coded numbers with
> #defines or is that best left for 2.4.1?
It wouldn't work anyway. There has to be _one_ interrupt stack per
CPU. When an interrupt happens (or a certain bit is set in an
exception vector), the CPU saves SP in the USP or KSP register
(user or kernel SP) and loads SP from the ISP register. USP and
KSP are considered part of process context and are saved and restored
across context switches. ISP is not.
Thinks out loud...
Or maybe we could play tricks with ISP during the context switch...
It would certainly be made simpler by Linux's all-or-nothing approach
to enabling/disabling interrupts. (In contrast to VMS which makes
extensive use of the VAX's 31 interrupt priority levels. Process
re-scheduling happens at priority 3, devices interrupt at priority 16-23,
power failure interrupts at 30, for example.)
Or maybe not... What if a device interrupted at IPL 20. Another
device could interrupt at IPL 21 in the window before we block
all interrupts in the first interrupt handler. Then this second
handler triggers a resched. If we switch to a different interrupt
stack then we'll destroy the stack context of the first handler.
Unless we either copy around the stack context (ugh) or map the
same physical stack into each task_struct. Seems a bit wasteful.
I think I'll go for the 'current is in a well-known register'
approach and see how this goes...
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:13 EST