You must have at least 4 code & data descriptors and the null descriptor. By putting these descriptors into an LDT you can have a maximum of 8190 TSS descriptors at any one time.iammisc wrote:If the task state selectors must be located in the GDT(correct me if i am wrong) then there can only be about 8192 task state selectors which means that only 8192 processes which have different address spaces can be running at a given time. So is there a way to get around that?
....First, I'd recommend not relying on the ISR for any part of the task switch itself. The reason for this is that there are kernel functions which cause a task switch without any interrupt (for example, "sleep()", spawning a new task, sending or receiving IPC, etc). Instead I'd use a single "do task switch" function that can be called from the ISR or from anywhere else.iammisc wrote:The isr will automatically pop the task state or do I have to program that myself? I still am confused as to software task switching are there any tutorials you know of(besides the one on osdever.net)?
Code: Select all
;Switch tasks
;
;Input
; eax = address to store current task's ESP
; ebx = address to get new task's ESP
do_a_task_switch:
pushfd
cli
cmp eax,ebx
je .done
pushad
mov [eax],esp
mov esp,[ebx]
popad
.done:
popfd
retCode: Select all
;Find a new task to run
find_next_task:
... make this up...
call do_a_task_switch
retCode: Select all
;Timer ISR
;
;Note: Interrupts disabled
timer_ISR:
call send_EOI_to_the_PIC
call find_next_task
iretdCode: Select all
;Terminate the current task
terminate_task:
... make this up...
call find_next_task
ret
;Stop this task (make it blocked)
stop_task:
... make this up...
call find_next_task
ret
;Start a blocked task
;
;Input
; eax = Task ID for task to restart
start_task:
... make this up...
if (started task is more important than the currently running task) {
;Switch to the more important/started task
call do_a_task_switch
}
ret
;Create a new task
spawn_new_task:
... make this up...
call start_task
retI hadn't considered doing things that way before. Something about it gives me pause... I think maybe you can get away with it because you're writing your kernel in assembler.Brendan wrote: First, I'd recommend not relying on the ISR for any part of the task switch itself. The reason for this is that there are kernel functions which cause a task switch without any interrupt (for example, "sleep()", spawning a new task, sending or receiving IPC, etc). Instead I'd use a single "do task switch" function that can be called from the ISR or from anywhere else.
What happens if send_EOI_to_the_PIC, or perhaps the first part of find_next_task before the stack switch, accidentally messes with one of the interrupted thread's registers? If you're implementing your scheduler in C, you'd have to save at least some registers in your ISR stub before calling into C code. If you're doing it all in assembler, you'd better have a really good attention span...Code: Select all
;Timer ISR ; ;Note: Interrupts disabled timer_ISR: call send_EOI_to_the_PIC call find_next_task iretd
Then it'd be a bug!Colonel Kernel wrote:What happens if send_EOI_to_the_PIC, or perhaps the first part of find_next_task before the stack switch, accidentally messes with one of the interrupted thread's registers?
How about something like this:Colonel Kernel wrote:If you're implementing your scheduler in C, you'd have to save at least some registers in your ISR stub before calling into C code. If you're doing it all in assembler, you'd better have a really good attention span...
Code: Select all
;Timer ISR
;
;Note: Interrupts disabled
timer_ISR:
push eax
mov al,0x60
out 0x20,al
pop eax
call find_next_task
iretd
;Find a new task to run
find_next_task:
pushad
... make this up...
call do_a_task_switch
popad
ret
;Switch tasks
;
;Input
; eax = address to store current task's ESP
; ebx = address to get new task's ESP
;
;Note: Caller MUST save general registers before calling, and restore them
; after the call, for e.g.:
; pushad
; call do_a_task_switch
; popad
do_a_task_switch:
pushfd
cli
cmp eax,ebx
je .done
mov [eax],esp
mov esp,[ebx]
.done:
popfd
ret
;Start a blocked task
;
;Input
; eax = Task ID for task to restart
start_task:
pushad
... make this up...
if (started task is more important than the currently running task) {
;Switch to the more important/started task
call do_a_task_switch
}
popad
retWhy do you need to know where in the kernel you are after you return from "do_a_task_switch()"?Colonel Kernel wrote:The other thing that weirds me out about this is that every time you return from do_a_task_switch(), you no longer know where in the kernel you are.
Ahh. I have a re-entrancy lock around the "wake_sleeping_tasks" code which postpones any task switches until the lock is released. That way 100 tasks can wake up at the same time and the scheduler would only switch to the highest priority task after they've all been woken (rather than doing 100 task switches as they are woken up one at a time).Colonel Kernel wrote:Let's say thread A makes a sleep() system call, during which do_a_task_switch() is called. Let's say the kernel switches to thread B, which happily runs until a timer interrupt occurs. The timer ISR calls the scheduler, which notices that A's timeout is up, and that it's priority is higher than B's, so it calls do_a_task_switch() to switch back to A. The problem is, A's kernel call stack is set up to complete a sleep() system call, but in fact the kernel is in the midst of processing a timer interrupt. I assume this is why you put send_EOI_to_the_PIC before find_next_task... otherwise all hell would break loose.
What happens if one ISR is interrupted by a higher priority IRQ/ISR?Colonel Kernel wrote:Instead, I save the registers in all ISRs before calling into C code. Any kernel code that wishes to effect a task switch returns a pointer to the new context (sitting at the bottom of some other kernel stack) to the ISR stub, which does the stack switch, pops all the registers, and irets. This way, regardless of what's happening with the tasks, it's always clear where control flow in the kernel itself is going. This is similar to the way that NT works, and also Minix (although Minix has just one kernel stack, while my OS will have multiple kernel stacks -- one per thread).
That's the problem. I think you misunderstood the purpose of my thread A/thread B example. I was not trying to make a point about performance, but rather about the possibility of subtle bugs.Brendan wrote: Why do you need to know where in the kernel you are after you return from "do_a_task_switch()"?
In all cases you are where EIP says you are, and "do_a_task_switch()" always returns to the code that called it (except for when a new task is created, where it'd return to where-ever the "create_new_thread" code tells it to return).
). Did you read that other thread I linked to?I don't see how this relates to the example I gave...Ahh. I have a re-entrancy lock around the "wake_sleeping_tasks" code which postpones any task switches until the lock is released. That way 100 tasks can wake up at the same time and the scheduler would only switch to the highest priority task after they've all been woken (rather than doing 100 task switches as they are woken up one at a time).
For now, yes. Not because it performs well, but because it's simple and I actually need to get something working before the end of the decade.What happens if one ISR is interrupted by a higher priority IRQ/ISR?
Let me guess - you disable interrupts within the first ISR so that it can't be interrupted.
Brendan wrote:If interrupt nesting is done correctly it would improve the interrupt latency of the higher priority IRQs at the expense of lower priority IRQs. This is a good scheme until you think about shared IRQs on the PCI bus, where your high speed network card might be sharing an IRQ with the sound card's MIDI.
For my OS the code to send a message will disable interrupts to reduce the time between acquiring the spinlock and releasing it, and as sending messages is the only thing the ISR does interrupt nesting would be a waste of time. For OSs that handle the IRQ within the ISR (e.g. monolithic, or micro-kernels that run device drivers at cpl=0 in kernel space) nested interrupts are much more important.
I don't have a scheduler implemented yet (been stuck on MM for a long time), so... no, your guess is off.For your system (if I understand it correctly), "ISR B" disables interrupts, does it's thing, and causes a task switch to "Task B" during it's return (where interrupts would become enabled again). As soon as interrupts are enabled the CPU starts "ISR A", which does it's thing, and causes a task switch to "Task A" during it's return. In this case the priority of the IRQ's was ignored, there was 2 task switches instead of one and the high priority IRQ A suffered a large amount of interrupt latency because of the unnecessary task switch.
Is my guess close?
Or maybe not. I don't know, I can make up whatever answer I like. This is why design is the cheapest time to change things! ;DI understood your thread A/thread B example, and was trying to point out that while not returning from "do_a_task_switch()" into a known state may be a little more complex, it's unecessary and there are (or can be) reasons not to.Colonel Kernel wrote:That's the problem. I think you misunderstood the purpose of my thread A/thread B example. I was not trying to make a point about performance, but rather about the possibility of subtle bugs.In all cases you are where EIP says you are, and "do_a_task_switch()" always returns to the code that called it (except for when a new task is created, where it'd return to where-ever the "create_new_thread" code tells it to return).
How about the page fault handler? The page fault itself causes you to enter the kernel, but if the page fault handler needs to load a page of data from disk (e.g. from swap space) then you have to do a thread switch before you return from the page fault handler. If the page fault is caused by trying to access an area that is used for a memory mapped file, then the page fault handler may need to switch to the virtual file system driver, which would need to switch to the correct file system driver, which would need to switch to the hard disk driver, which may block waiting for a "data transferred" IRQ and allow other unrelated tasks to run until this IRQ arrives.Colonel Kernel wrote:Thinking on a high level for a second -- every time you enter the kernel it's for a specific purpose, and there are some mechanics going on related to that purpose that must be carried out consistently. Sending an EOI to the PIC in an ISR is a perfect example. I'm sure there are others (perhaps not many in a microkernel, but who knows what weird and wonderful things the monolithic guys want to do
But there are exceptions to this. One example would be a "get a message" system call, where the task blocks if no messages are currently available for the task. In this case "do_a_task_switch" is often called after checking if any messages are available, but before the "important thing" (or getting the message) takes place, and certainly not as the last thing before iret.Colonel Kernel wrote:My point is, if you look closely at where you're calling do_a_task_switch(), it's always getting called after these important things take place. This is a rather important constraint on the use of this function that I think you take for granted. For a newbie, it's very subtle. With my approach, the actual context switch always takes place at a "safe" time (the very last thing before iret).
That's a fair comment, but possibly I changed my mind because my original plan wasn't good enough for me!Colonel Kernel wrote:Besides, you were doing it the same way last year, and if it was good enough for you, I decided it was good enough for me. It's not my fault if you keep changing your mind.
Unnecessary to do what? Return to an unknown state?Brendan wrote:while not returning from "do_a_task_switch()" into a known state may be a little more complex, it's unecessary and there are (or can be) reasons not to.
IMO that's an odd way to implement any handler. I think of each handler/system call/interrupt as an event that potentially changes the state of a thread. At a high level, the control flow of an OS is a bunch of related concurrent event-driven state-machines. I'd rather model this in a more controlled manner, rather than relying on the state of some thread's kernel stack to "remember" what was happening when that thread was blocked for whatever reason.How about the page fault handler? The page fault itself causes you to enter the kernel, but if the page fault handler needs to load a page of data from disk (e.g. from swap space) then you have to do a thread switch before you return from the page fault handler.
That's an example of a case where your scheme magically works because copying a message to the receiving thread's buffer is not really a critical operation the way sending an EOI is (i.e. -- it's something that could happen before iret, or could not, either way it doesn't bring the system down).But there are exceptions to this. One example would be a "get a message" system call, where the task blocks if no messages are currently available for the task. In this case "do_a_task_switch" is often called after checking if any messages are available, but before the "important thing" (or getting the message) takes place, and certainly not as the last thing before iret.
Did allowing nested interrupts fix this? If so, how? I briefly forgot that the kernel itself ought to deal with the timer in its own ISRs.At the time I had (unrelated) design problems with level triggered interrupts, and (more recently) interrupt latency problems that caused IRQ8 to be missed on some computers which led to the OS locking up/waiting forever (although this could be attributed to setting the RTC periodic timer's frequency too fast).
