“Some oppose a preemptible kernel because of throughput concerns. Others oppose preemptibility because of concerns about growing complexity in the kernel. This argument is specious, because the preemption approach takes advantage of already required and in place SMP locking. No additional complexity is created. All Linux kernel engineering must already take into account SMP requirements. Some oppose continued refinement of SMP locking to achieve better SMP scaling (on higher way SMP systems); such refinement has the beneficial side effect of also reducing preemption off periods in a preemptible kernel.” Read the rest of the editorial at LinuxDevices by Kevin Morgan who is the Vice President, Engineering at MontaVista Software.
Preemptible Linux – A Reality Check
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m puzzled why Linux is dragging its feet in this area.
There are so many performance gains from making the kernel preemptible. In the early days of PetrOS, I had a single system wide mutex to control critical resources which would be the close to the equivalent of a non preemptible kernel. I ran into serious performance problems when there was contention for this mutex.
Moving to multiple mutexes wasn’t easy as there were plenty of deadlock issues to work through, but the performance shot through the roof after that. The system wide mutex is still there but I peel off subsections when needed. The advantage is that subsections of the kernel can operate independently (e.g. TCP/IP vs File system vs Virtual memory) so when there are spare cpu cycles or a job tied to an interrupt needs to be done, life goes on.
I read a comment somewhere that Linus Torvalds was the one who said no to this (correct me if I’m wrong) – perhaps it would be good to obtain his views as to why this is the case if it is true.
P
Well, assuming that you’re on a single-CPU system, it’s quite likely that using a giant lock around the kernel will improve throughput, at the cost of adding a bit of latency. For a Unix, throughput is at least as important as latency.
–jbq