Messages in this thread |  | | Date | Mon, 9 Oct 2000 23:26:16 +0100 | From | Kenn Humborg <> | Subject | Re: Calling current() from interrupt context |
| |
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/
|  |