Andrew Morton And The Low-Latency Kernel Patch
An Anonymous Coward writes: "KernelTrap has interviewed Linux kernel hacker Andrew Morton, author of the low-latency patch. Though his patch has received less attention than Robert Love's preemptible kernel patch (recently merged into the 2.5 kernel), it results in quite significantly lower latencies. The interview is quite interesting, delving into the low-latency patch, explaining how it works and the differences between it and the preempt patch. He also talks about his ext3 work, porting that journaling filesystem from the older stable 2.2 kernel to the current stable 2.4 kernel."
A day in the life of a kernel hacker.
PHP == pointy haired programmer ?
Escher was the first MC and Giger invented the HR department.
"With an internally preemptible kernel the explicit task yielding is not necessary, because the context switch is performed in the interrupt return path and via open-coded yields which are hidden in the unlock code. But you cannot preempt an in-kernel process while it holds locks, so all the unlock, relock and fixup code is needed in either approach."
:)
Try getting your head round that one when needing sleep
Andrew Morton And The Low-Latency Kernel Patch
:)
.)"
Sounds just like a title of a bedtime story.
I also recommend you read "How CowboyNeal saved the world (with a little help from / and
I'm now running 2.4.18pre9mjc2 with preempt & O(1) patches. Now I'm running a crazy prime-factoring program that forks a new process to do one division. It is now niced to 19. The system is running quite smoothly. (X is niced to -10)
`uptime`:
4:06pm up 1:44, 6 users, load average: 337.62, 241.84, 115.30
My box is a plain-old PII/233.
The only problem is that now any unniced process that does real cpu-intensive work (as opposed to interactive ones) can get only about 20% of cpu. It is just blatantly unfair to let one unniced process compete with 500+ others, even though they are niced to 19.
Of course, the programs I'm running does not take too much memory. When one run out of memory (like make -j), the system will swap like crazy, then it IS unresponsive.