Slashdot Mirror
Preemptible Kernel Patch Accepted
An Anonymous Coward writes: "The preemptible Linux kernel patch that was originally introduced by MontaVista Software and more recently championed by Robert Love has been merged by Linus Torvalds into the main linux development-kernel tree, beginning version v2.5.4-pre6. This adds a far greater degree of real-time responsiveness to the standard Linux kernel, by reducing
interrupt latencies while kernel functions are executing. The story at LinuxDevices.com includes comments by Robert Love, and there is also a recent interview with Robert Love about the preemptable kernel here and a whitepaper about the technology by MontaVista here."
I thought that the preempt patch was quite a way from being part of the linus tree. On the other hand, early in a development kernel is probably the right place to integrate it, so that all those device drivers with problems with the preempt stuff (like NE2000, I think) can get fixed.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
If you don't like it, treat it the same way as SMP...turn it off!
The fact that this is built into the kernel means that we don't always have to go out and download patches to change this. I would assume that vendors using the Linux kernel would make decisions on how to compile the kernel to suit their environment.
There are lots of people that are frustrated by the current need to go and get patches to change this. Incorporating it into the main kernel should be very positive, IMHO.
Aside from the technicalities of this particular patch, your assumption that you're going to lose something when you apply a beneficial patch because 'you don't get anything for free' is, despite appearing mature and clueful, way off mark.
The cost doesn't have to be borne by the end user. The cost can be developer time / clues. In the Free Software world, you do get that for free.
Yours Sincerely, Michael.
I know that I shouldn't ask this because there has already been enough changes and troubles in 2.4 - but I've got some Karma to burn:
Wasn't this patch long enough available on 2.4 so that it should be stable enough?
$random = md5(microtime());
...
if (!file_exists("/tmp/$random")
$fd = fopen("/tmp/$random", "w")
The problem is the symlink/race condition issue that prompted the need for a kernel-level function. Or is there a way to prevent that from being preemptable?
"Do you really want any user to pre-empt the processing in the kernal by CPU to the detriment of other users? A more logical answer to this is to have set guarantees as how much processing time is given to each user."
Actually, I would think it would be the opposite. Being able to preempt within the kernel can pretect you against a DOS attack where a process repeatedly makes long running kernel calls. That would give that process more than it's fair share of time, and other processes couldn't respond to interrupts as well. Without a fully preemptable kernel, you can't guarantee how long a process can run, because it is impossible to preempt them while they are in a kernel call.
-no broken link
Consider, however, the case where the reason a task is preempted in the kernel is that it has used all of its timeslice. Without the preemptable kernel patch, the task cannot be interrupted to schedule another task. In order to make guarantees about how much time will be given to each process, it needs to be possible to stop a process when its time is up essentially no matter what the process is doing.
The issues you raise are a matter of scheduling policy, not of whether the kernel is preemptible. Furthermore, for most interactive tasks, the correct behavior is to react quickly, because those tasks haven't used up their timeslices, since they blocked waiting for input. In this case, interactive processes give up the CPU to wait for input, and then get their time back as soon as they have a use for it.
Of course, this all also applies to tasks which "interact" with the network or the hard drives, which is any task when you have swap space. Processes which are waiting on input want to run as soon as their input is ready, and don't care about time before that. Processes which are not waiting on input want to run as much as possible, and don't care exactly when. Having the scheduler's instructions followed as closely as possible benefits both kinds.
Not quite true - some Linux patches give unilateral improvement. But I do see your point.
None of the other responses to this thread (that I've noticed) addressed one tradeoff: complexity and bugs. Ever since Linux started to support SMP systems, SMP kernels have been somewhat buggier than UP kernels. This is because there are a lot of potential mistakes to be made - getting and releasing spinlocks and semaphores at the right places is not trivial stuff. Of course bugs have been fixed over the past several years, and SMP is now considered a standard Linux feature (in 2.0 it was "experimental"), but there are still no doubt lots of SMP bugs in some of the more obscure device drivers.
The problem with the preempt patch is that it introduces all these potential bugs into a standard non-SMP kernel, since preempt uses much the same basic mechanism as SMP. Most people only have one CPU, but now these people will be exposed to the same "increased level of risk" as SMP systems.
In a way, that could be considered a benefit - this may serve to flush out some of those last remaining SMP bugs. The SMP code paths will be exercised by a lot of people now.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
The linker definitly needs some work on linux. Program startup can be painfully slow especialy when using KDE (C++). This really gives the feeling of a slow system, even though when the programs are finally started, they run rather snappy.
Redhat 7.2 has a prelinker utility on the cdrom although it is unsupported. I tried it out. Installed it, and ran the prelinker on all binaries in the default path (it appears to include most libraries and binaries). The improvement was negligible if even there.
Any Ideas on how this could be improved in the future. I have two ideas that I can think of to improve the linking performance, or at least improve the feel of the linking.
1. Memory pages that are linked, but not dirty(Havent been updated since) could be marked as part of a link cache. For instance the same program starting up could just ajust it's page table to point to the already linked page, and update the page count. The page would then be copy on write. These pages would be usable until the reference count is zero, and the system needs the page for other purposes. This would impove load speed as long as the program was previously used, and it's pages haven't been used for other purposes. This would be great for multiple use systems like a terminal server. I don't know if this is possible, or already been done, and I'm behind the times.
2. Simple start up tricks. For instance the window manager opens a frame where the program is going to start up. The frame would contain a throbber, status bar, etc. The frame would resize once the program connects to the Xserver to surround the first window of the application.
I hope these posts aren't too off topic.
Thanks.
Adam
This is not true in case of workstations, whose primary purpose is to provide smooth and fast environment for people to work, not to crunch numbers.
Neither does your assumption hold for embedded systems - their function is often to provide fast responce to external signals, which they can do much better now. Most embedded systems don't utilize 100% of the processor power either.
It is only in the case of servers with heavy I/O that your reasoning makes sence. But the solution is in the hardware - use bigger blocks of data, and the processor won't be interrupted too much.
I've tried the patch under various kernel versions under heavy desktop/X11 load, and it only makes the problem worse - instead of slowing down the system immediately, the system gets slower on a delay, and disk I/O is done in chunks instead of when it's supposed to be done. All in all, this patch just makes the kernel respond even slower than without the patch. Things like unRARing files or apt-get upgrade-ing the system will slow down X11 to almost an unusable state with this patch, while it is bearable without the patch.
i think you have no idea what you are talking about.
:)), but any application could get supervisor mode if she wanted to) and just look at all the places in exec that simply did
the amiga had no kernel at all. there was no difference between kernel space and user space. (ok, some few things had to be done in supervisor mode (eg stop #$xxxx
move.w #7fff, $dff01e (ie stop interupts!)
I seem to recall that one of the bigger issues was that Linus wanted the problems to be fixd, not the symptoms.
That is, the correct way to fix this was not to make the kernel pre-empt., it was to make the slow parts in the kernel faster.
Seems like he changed his mind on that account though. (Or perhaps he just figures that this is a good way to "fix it for later". I would assume that they [core kernel hackers] have enough to do in any case.
And naturally the patch can (and has) introduce new bugs into the kernel which are complicated to debug. (Since when the kernel/driver were written it was assumed that it would be non pre-empt.)