OSDev.org

again me: /dev/brain is rambling around the following stuff due to the recent discussion about scheduling in linux 2.6 kernels (this o(1) stuff with the two priority queues - I have finally got it)

What about giving time slices to device drivers too? so that the floppy driver can be eventually preempted by the mouse driver and vice versa in round robin manner. So that a service can be preempted by another service or has to give up cpu and let others get their share of cpu time?

My current aproach is Top Down: i.e. User app asks service and blocks. Service eventually needs something from device driver and blocks. device driver does the dirty work, returns data to the service (as working in the address space of the service this is sometimes as simple as copying data over to a buffer in the service). service processes the data and returns reply/data to the userland process.

you see, the kernel components all run as long as they need cpu. No preemption will ever happen inside a priority, i.e. if floppy has the cpu, mouse can way till it gets black if floppy is caught in an endless loop == bug!!?It requires the device drivers to act in a straight forward manner and to keep execution paths as short as possible.

Hm ... I need to think more about it. Much more. Anyway, where 'd be the fun if it weren't for things like this showing up occasionally.

i was hacking around the linux netfilters recently and unfortunately discovered that my code could run a silly loop in some condition.

No luck: my code was apparently called in a NIC interrupt and nothing at all responded anymore on the PC...

Though, the PIC can be programmed so that more prioritized interrupts (imho, keyboard should have the priority, was it only for CTRL+ALT+WIN+SHIFT+SYSRQ+PAUSE martian key combo and IRQ should be re-enabled once the driver made sure everything "previsible" has been done.

Okay, while receiving bytes from the NIC/harddisk/whatever should be done with IF cleared ... and in a microkernel, probably the netfilter or the route tasks would be handled by some separated service task rather than in something like an interrupt handler...

you may want to check out my server model for more ranting about it ...

What about reprogramming the priority on these things not so much to keep the computer completely occupied or at top speed, but to make the UI parts most prioritized?

Say:

1. Graphics Output
2. Sound output
3. Force Feedback output
4. Keyboard/Mouse/Gamepad/Joystick etc. input
5. Graphics Subsystem (includes windowing subsystem)
6. Network
7. Harddisks
8. USB stuff (excluding stuff listed above, if possible, see also rant below)

The logic is that you want the user to percieve the best response (so the top X threads have an absolute priority, IE, if they're ready they run, no care for starvation) but you also want reasonable response for the rest (so it's still in absolute priorities above the rest. For relative priorities, the top X should be combined into a single "task" that runs for at most 40% of the time, but can use, if threads are ready, at least 20% of the time. This way, the threads all get a chance to run, will run even on systems with a very high load and will always give the perception that all is OK. Even when you run 1750 threads at a time.

Not sure whether it'll work very good in any way, but I think it will... This is mostly based on the assumption that an interrupt does not invoke a direct handler but calls a small (very limited) function that decides whether the interrupt should be accepted. This function should be between 1 and 1000 cycles. If not, it's passed on (chain of responsibility, but then explicitly), if so, the accompanying thread is activated (set to runnable) and run next time around. This way, the interrupts don't mess up the cycle times as badly as they commonly do.