In response to a recent bug report on the lkml, Jeff Garzik, the maintainer of the Serial ATA subsystem and network device drivers, had some harsh words for kernel preemption. In the bug report it was mention that kernel preemption was enabled to which Jeff replied, “I strongly recommend disabling kernel preemption. It is a hack that hides bugs”. The comment lead into an interesting discussion.
Linux: Debating The Merits Of Kernel Preemption
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
http://kerneltrap.org/node/view/2702
So what is the verdict this time?
“and would happily sacrifice latency to high performance”
You can’t be all things to all men.
I’d always go for a low latency system as that will “feel” noticably faster, if you need high performance you will have to put up with high latency.
Years ago, kernel pre-emption was a feature touted by a handful of Linux zealots when arguing against FreeBSD. Nowadays, it’s very sad to see FreeBSD not attempting to tune the ULE scheduler and use it per default because of preemption bugginess, especially as the ULE scheduler is largely bug free and only exhibits poor performance in fringe cases whereas preemption is still incredibly buggy. Considering FreeBSD’s reputation as a server operating system, I don’t understand why they’re prioritizing things in this manner, except perhaps they’re simply keeping an eye towards maximum stability.
Kernel preemption lowers kernel throughput, plain and simple. For servers absolutely keep it off, it offers no benefits besides a slight decrease in response times at the price of substantially lowered kernel latency.
For desktops… well, it’s up to you. I still say bad idea.
…price of substantially lowered kernel latency.
Correction: substantially lowered kernel… throughput
What’s the percentage of performance loss do you think?
In theory, there should not be a significant overhead because of kernel preemption. The necessary locking is nearly the same as what is required for SMP systems. It creates overhead in the single-CPU case, but since everyone seems to be going multicore these days, that doesn’t matter.
With regards to servers, it should be noted that both NT and Solaris have preemptible kernels. Implemented properly, it shouldn’t hurt performance appreciably.
Years ago, kernel pre-emption was a feature touted by a handful of Linux zealots when arguing against FreeBSD. Nowadays, it’s very sad to see FreeBSD not attempting to tune the ULE scheduler and use it per default because of preemption bugginess, especially as the ULE scheduler is largely bug free and only exhibits poor performance in fringe cases whereas preemption is still incredibly buggy. Considering FreeBSD’s reputation as a server operating system, I don’t understand why they’re prioritizing things in this manner, except perhaps they’re simply keeping an eye towards maximum stability.
I agree… I don’t understand why either…
how much will it increase my doom3 fps?
Interesting read. I wonder though: kernel preemption was extremely helpful when I was using FC1 (which defaulted to a 2.4 kernel. It was rather stable and in fact felt much more responsive. With his 2.6 patches, however, Con Kolivas actually suggests against using it. Is this argument against preemption solely for the 2.6 kernel branch?
It may be worthwhile to point out that an anonymous followup to the piece on kerneltrap.org asserts that Jeff Garzik was only recommending that developers and testers disable preemption in order to help them see evidence of excessive latency in the code and to better see bugs which might in some way be concealed by kernel preemption. However, it was stated, users should run with it enabled because “Preemption results in lower worst-case latencies which is exactly what you want as a user so your MP3s don’t skip or your digital recordings aren’t filled with gaps and jitter.”
If true, then his advocacy sounds much more reasoned than it might otherwise. Linux developers are said to expend a lot of effort on keeping the code lean and fast… that they don’t get lazy and stop once the code works, but that they continually work towards making the code more efficient, as well. The Linux system call code was offered as an example of this attention to detail. I like this idea and would agree that the kernel preemption feature does not provide an excuse to get lazy about the latency of code paths in the kernel code.
With regards to servers, it should be noted that both NT and Solaris have preemptible kernels. Implemented properly, it shouldn’t hurt performance appreciably.
Yes, “implemented properly” being the keywords. Solaris has non-preemption points inside the kernel to prevent kernel preemption from negatively affecting throughput. Solaris is, in general, a high latency kernel tuned for throughput however…
how much will it increase my doom3 fps?
It won’t.
Heh. Stupid, slightly off topic question, but isn’t preemption one of those things that the Hurd’s architecture is supposed to be well suited for?
Just curious, because it’s monsterously slow development aside, I’ve always thought that it was a neat OS in principal, if not yet in practice.
why not have a run-time option to set the behavior, like having run-time schedular policies switching. some situations may eveb benefit from a continuous variable (0 – 100%) between never pre-empt and always allow preemt?
Why make it so difficult?
If you want your Linux to run on a server, disable kernel preemption.
If you want your Linux to run on a desktop, enable kernel preemption.
Everything else is a bug, IMNSHO.
If you want your Linux to run on a server, disable kernel preemption.
If you want your Linux to run on a desktop, enable kernel preemption.
That’s my impression too.
Old Amiga fans and audio people, like myself, know the importance of preemption and RT scheduling. This is important.
Surely it depends on what your wanting to use it for? One of the better things about the Linux kernel is that you can pick-and-mix versions of it.
Of course, I agree that if the kernel was better suited to low-latency in the first place… and somethings cannot be pre-empted (low level driver code often among them).
Bit of a storm in a teacup really…
I agree with what has been said about ULE. And the ironic thing is that when option PREEMPTION appeared in the kernel, the first thing I did to change back to 4BSD, and lo: I had three total freezes. ULE was removed b/c it caused crashes with PREEMPTION, but it turned out that it wasn’t really the culprit. I tried PREEMPTION with ULE as well, and I didn’t have more lockups (didn’t have less either).
And it is so much a pity!!! When I first switched to ULE (late 5.1 series), I didn’t know if it is better or not (it felt better, but only by a small margin, and I didn’t know if it is really better, or I’m just imagining). Now I know why I like it! You can’t even compare desktop performance (especially under heavy load) with SHED_4BSD. Yesterday I had to switch back to a terminal to see if compile (ran into library update between beta6->7, and I’m recompiling affected ports) hasn’t stopped. It is that good! With ULE I could watch movies while compiling in the background, mouse cursor (one of the most visible signs of 4BSD) didn’t lag if under load, program startup is reasonable. And I never ever had a crash that could be traced to ULE until PREEMPTION (which, just I said, crashes with 4BSD as well).
Many users were surprised to see that ULE didn’t became default for 5.2/5.2.1! That was the biggest mistake I think. Since 5.x was a “New Technology Release”, users would have accepted the risk (if there were any). And FreeBSD would have had seven months to hammer out bug, not a few BETAs. And now we would have a kickass scheduler by default, wich has not only better SMP capabilities, but it is better on UP machines as well (like mine).
Actually thats a very good question. The answer is don’t bother. It is better to throw more hardware at a problem like that. With pre-emption and things you are looking at the response of the system handleing multiple tasks which might be more suitable for a computer in a car (something that I am currently looking at building and it probably will not have an OS). Becuase most games have one to three threads preemtion gets you zip unless you are running at say <10MHz in which case you would be better off redesigning the game to not switch threads so often or remove the threads altogether.
In summary preemtion is good for hundreds or thousands of tasks not a few tasks.