I didn't think not being pre-emptable is not a hindrance to running on multiple CPU's, linux was not-preemptable until relatively recently.
I am putting in spinlocks now to avoid having problems later, so I am thinking of how my design will grow.
Incidentally I have just coded my pre-empt protection into the kernel. Basically what happens is that when a kernel interrupt is called, the first instruction marks a flag that says "the kernel is in use, dont pre-empt" and clears this on exit.
My design means that complex calculation is not meant to be done during a system call. And hardware interrupts will still be able to happen if a system call is executing to avoid holding up I/O.
I reckon my design will avoid the need to disable interrupts at any point, which should help transition to multi-processor at a later point.
Update: I am getting into a right mess with my non-preemptable kernel, so I think I will switch to pype's mechanism for esp/ss restoration. Now to get it to work, I still getting GPF's at the moment
SS/ESP on stack after interrupt
Re:SS/ESP on stack after interrupt
Pre-emption on a single CPU has the same overall effect as running the same code on multiple CPUs, although, granted, the (imaginary) problem that you see with stacks won't happen on multiple CPUs (and it won't happen on single CPUs as we've explained).
If you want to take advantage of multiple CPUs, you have to be able to run the same code on more than one CPU, correct? The example you gave of Linux not being pre-emptable is a good one: that fact hurt performance of Linux on SMP systems. At one time, there was one big spinlock around the kernel (i.e. only one task could be in the kernel at once).
In an ideal world, you'd have a spinlock on every piece of shared data (that is, every piece of data that you expect more than one thread to access during the lifetime of that data). However, spinlocks aren't free: the cost of checking (even without spinning) isn't negligible.
If you want to take advantage of multiple CPUs, you have to be able to run the same code on more than one CPU, correct? The example you gave of Linux not being pre-emptable is a good one: that fact hurt performance of Linux on SMP systems. At one time, there was one big spinlock around the kernel (i.e. only one task could be in the kernel at once).
In an ideal world, you'd have a spinlock on every piece of shared data (that is, every piece of data that you expect more than one thread to access during the lifetime of that data). However, spinlocks aren't free: the cost of checking (even without spinning) isn't negligible.
Re:SS/ESP on stack after interrupt
Just to let you know, thanks for the help, I now have stack switching working a treat using a variation of Pype's example.
It will need to be tweaked slightly when I get user programs being interrupted by interrupts, but that will be a small matter of making sure that the dpl change ss/esp need putting on the stack.
Thanks a lot, now thats working back to my I/O system!
It will need to be tweaked slightly when I get user programs being interrupted by interrupts, but that will be a small matter of making sure that the dpl change ss/esp need putting on the stack.
Thanks a lot, now thats working back to my I/O system!