I usually offload most of the work to kernel server threads, but I still run most of the interrupt handlers with interrupts enabled. The drawback of disabling interrupts in the interrupt handler is lousy interrupt latency, which you don't want in a kernel that wants to be highly responsive. (Some other work will have to be done, such as creating and scheduling a new thread object to represent your handler-turned-thread.) It's less effort to just keep interrupts disabled while in your interrupt handler and to create a kernel thread to do the work. You could turn your interrupt handler into a long running thread, by assigning a new stack in the TSS before calling 'sti'. If it's a long running operation, you can put the user thread to sleep and kick off a kernel thread to do the actual processing work, then return from your interrupt handler. Keep your interrupt handlers short and sweet. The easiest and most common thing to do is keep interrupts disabled while in the interrupt handler. Is there an obvious answer here or are any of these valid design choices? Its entirely possible I am overthinking this. Furthermore, I think I will face the fundamental issue again with user mode multithreading when multiple stacks must share the same memory space. And this option gets less elegant when there are multiple kernel stacks per process. Option 3 seems like it would be the most flexible, but I'm not sure what pitfalls I may encounter if processes start having different kernel memory maps. I think this is what linux does? Option 2 might be a bit more flexible but still requires choosing a maximum stack size and thus has the same issue as option 1 (limited by finite virtual space rather than physical space). Option 1 is simple, but kernel processes need to be very careful not to overflow their stacks (no recursion, etc). Each stack (or at least one per process) can grow down arbitrarily until it hits the heap Option 3: Processes each have their own individual memory map for kernel stack(s). Kernel stacks can grow slightly, until they hit another stack
Option 2: Processes share all kernel memory, and kernel stack virtual addresses are spaced out a bit. Option 1: Processes share all kernel memory, and kernel stacks are allocated sequentially in virtual memory. There seem to be at least 3 ways of mapping the kernel stacks that I can envision: using a guard page) and if so, how to implement this.
My main question is whether kernel stacks should be allowed to grow beyond their initially allocated size (e.g. I'm a bit confused about how to best manage memory for kernel stack(s) in my 32bit OS.
0 kommentar(er)
