Slashdot Mirror
Robert Love, Preemptible Kernel Maintainer Interviewed
Tom F writes: "LinuxDevices did an interesting interview with Robert Love, the maintainer of the Linux preemptible kernel along with MontaVista. It is an exciting read and has Robert's usual wit and insight."
I do believe that what Love is working on is in fact a patch, and not a fork.
His comments on the preemptive kernel patch make me want to try it out. It seems like a great idea, and from what he says, it's well-implemented.
On a side note, he's my kind of geek. At least started with Slackware, kernel hakcs and even has a girlfriend. Wow!
Moderation: Put your hand inside the puppet head!
Where do these college students get all this time to hack on the kernel? Don't they have to study at all?
Love doesn't maintain a complete seperate kernel tree, just a patch that applies to the main Linus tree.
I'd also like to see an interview with the author of the low-latency patch as well as a comparison of the two. Bits I've read from Kernel Traffic give me the impression that people think the low-latency patch generally provides better responsiveness and scalability.
Like all true geeks, Love doesn't forget to include in his comments that, despite being a computer nerd, he does, in fact, have a girlfriend.
RL: Approximately how much time per week do you spend working on your kernel patch for Linux?
Love: My girlfriend would probably say too much. Anywhere from a couple hours a week to many hours a day.
Right now it's just a patch. But Linus has made it clear that he is unwilling (for whatever foolish reasons) to accept Love's patches. If the preempt patches become popular enough (as they no doubt will amongst those using Linux for multimedia production), it won't be long before somebody decides to fork the kernel with preemptible patches simply to make it easier to use for more people. From there, you could very quickly end up with yet another completely different operating system kernel.
Obviously, you want someone that knows the kernel really well and can maintain every part of it.
That person doesn't exist, not even Linus knows every part of the kernel inside and out.
You have to trust the maintainers of their parts of the kernel because as good as Linus, Marcelo, Alan, etc are they can't know all the gotchas, etc of all the drivers and different kernel subsystems.
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
They don't have to do it if they don't want to or don't have the time. But with Alan's recent want to not maintain 2.4.x so he can work on other things seems to say how much time is really required for the maintenance of a kernel tree.
There are only so many developers, what happens if you run out?
I highly doubt there will ever be that many currently maintained kernel versions.
If you maintain different kernels, people say "OHMYGOD we are forking we will all DIE"
If you roll changes into a kernel and make it unstable, people say "OHMYGOD production kernel's not stable we will all DIE"
RTFA and lighten up. The patches are being considered for 2.5. They haven't been ruled out.
www.eFax.com are spammers
>the Linux operating system will soon end up like
>*BSD, with several mutually incompatible,
> infighting factions. We can't let this happen.
Where on Earth did you get this nonsense from? There are three open-source BSDs, each with a different focus. Admittedly a few OpenBSD and NetBSD developers aren't the best of chums, but most of the developers are happy to share code between projects (eg. dirhash, smp, usb etc)
--Jon
Remember when you had to compile your device drivers into the kernel yourself instead of using a module? The idea here is that the vital OS features are part of the kernel.
The open source movement is about modifying your software and sharing it. Anyone with the ability can modify a vital OS feature and share it. voila! Many, many kernels.
But, the problem here is that real time processing does not belong in a macrokernel architechture. Look at the commercial RTOS (Real Time Operating Systems) like QNX and you will see that a microkernel architechture -- a kernel that a provides minimal feature set is favored. This is because if you are depending on time constraints, all you want in your kernel is message passing and task syncronization.
I'm supposed to be working right now.
a quick nice -n -5 /usr/bin/X11/X helps, too.
You need to spend some time studying history before
shooting your mouth off.
The main reason for BSD's "marginalization"
relative to Linux is the AT&T/Novell lawsuit.
It's also worth noting that the different BSDs are
no less mutually compatible than the different Linux
distributions.
Ben "You have your mind on computers, it seems."
I "grew up" in the 8-bit era and recall that we used vectored interrupts to handle real-time needs. That worked extremely well with processors running at 1/1000 of today's speeds.
After reading the article, I'm left wondering why "unpreemptable kernals" were ever conceived in the first case. To lower the cost of hardware? On the "limited-access freeway" model? Or just to K.I.S.S.?
"You must try to forget all you have learned. You must begin to dream." -- Sherwood Anderson
While there are different Linux distributions, these all use the same kernel and the same applications, usually built from the same sources. A Redhat binary will generally run fine on Mandrake or Debian or Caldera or SuSE or what have you. FreeBSD, NetBSD and OpenBSD have become completely different operating systems with vastly different userspace code. Binaries are not at all portable between the operating systems. This is a far deeper and more severe fork than Linux, and if we continue down the road of having more and more Linux kernels (as we are seeing now), soon the same deep, irrevocable split could happen to Linux as well.
There are only so many developers, what happens if you run out?
If the supply of Linux kernel developers runs out (as unlikely as that seems), then kernel developers get hired away from different kernels.
Seriously... there are folks who, for commercial reasons, need a lot of this work to be done; and a developer with real-time experience from a different UNIX kernel can familiarize with Linux within a reasonable amount of time.
For instance, quite a few of the folks MontaVista has hired to do kernel work come not from a Linux background but from working on other Unices -- one fellow we hired to work on preemptability originally did the same variety of thing for IRIX, IIRC.
I think some parts of NT are and some parts of not.. windows 9.x/me are definatly not to prove this just watch your whole system slow to a crawl while writing to the floppy drive.
I don't think even with this the kernel will be good enough for some forms of real time process control. Real Time process control needs guarunteed sub millisecond response times and everything else including overall throughout is sacrificed for the cause.
It will however make the UI a tad more responsive and make it harder for things like web browser loading to make the mp3 player skip.
Is the MS windows kernel preemptible? Does anyone know or is it top-secret?
AFAIK, it is not. I know that in Windows minimum latency is about 10ms, same as in default Linux kernel.
If a kernel is preemptible, can it be used for real time process control?
For what? Do you mean for something like.. robotics control? or shuttle devices control?
For that answer is a bit complicated, you see, even this pre-empt patch doesn't help when there are 'long' locks in kernel. There are situations when kernel disables all interrupts and does its things for long time (like 5 to 20ms). There are not many of these, but they do exist. Now, realtime kernel is one that answers any interrupt 'right away', and can be interrupted 'anywhere'. These are a LOT hairier than pre-empt patch.
If one doesn't have hard time limits, pre-empt patch delivers enough certainty on time-bounds..
fucktard is a tenderhearted description
Alan Bawden wrote a paper on it, and it's quite a good read. His web site has a compressed .gz version, but I found an HTML version of the HTML PCLSR Paper and I quote from its abstract here:
There was also a way to put the system into a PCLSR test mode that exercised all these control points within the system calls, to help debug them. See SYSDOC TEST documentation extracted from the now decomissioned AI PDP-10 that originally served it up as ftp://ftp.ai.mit.edu/pub/alan/its/sysdoc.tgz (yes, ITS was on the Arpanet and the Internet and ran TCP/IP as well).
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
Stability and code maintenance are just as important (or more important, in some cases) as new and exciting features. Work on older kernels isn't wasted -- any relevant fixes can be ported up to the devel version.
...Alan Cox's own fork which is steadily separating from Linus' core...
Well, Alan isn't really in the business of doing this anymore. But even when he did, that's not the way things worked -- the Alan and Linus trees stayed fairly in sync with each other in many ways.
A preemptive kernel is allowed to be stopped for another higher priority task, in the default kernel only userspace apps can be preempted. What this means is if an app is reading from the disk (the syscall for block I/O is run in kernel mode on the app's behalf) and the disk read is taking a long time (many milliseconds) that kernel path can be paused to allow other processes to run while the disk finishes it's read.
You mean about the lawsuit?
Linus himself has said that if BSD hadn't been
under a cloud of legal uncertainty in 1990, he
might not have embarked on the Linux project.
You can get more information about the lawsuit
here, just search for the string "the lawsuit".
Ben "You have your mind on computers, it seems."
I'm ignorant of this fact... but it almost sounds to me like having a pre-emptible kernel is one of the 'featues' of a MicroKernel --
Although I'm fully aware of the fact Linux is NOT a MicroKernel, what significant differences exist between Pre-Emptible Linux and a MicroKernel Linux?
(Aside from the fact that all of the Linux kernel, drivers, etc. is in 'kernel' mode, and a MicroKernel has only the message-passing and task-scheduling in 'kernel' mode, and everything else (drivers, etc.) run in 'user' mode.)
-- Sometimes you have to turn the lights off in order to see.
thats complete nonsense. the behaviour you're describing is what any multitasking kernel does. it has nothing to do with the preemptive kernel patch, which ensures that when a task becomes runnable (for example, due to a device interrupt that tells the CPU that a condition the task was waiting for is met), it can start running ASAP, rather than waiting till the next regular re-scheduling point. ASAP here means within at most a millisecond or two. There will be always be places where the kernel has to prevent this from happening; the goal is to minimize (and document) those places.
NT kernal is; at pretty much any time you can give the three finger salute and get the 'stuff to do' dialog. When you see a blue screen, that's NT having caught an exception that worries it enough to *voluntarily* halt itself, because it can no longer guarentee that it's working with valid data. It also spews out a large amount of debug data. Most such bluescreen occur due to hardware drivers. This is similar to a UNIX kernal spewing a bunch of kernal panic messages and the like to the syscon, then halting. Very rarely will you see an NT derived kernal simply 'freeze.'
Vintage computer games and RPG books available. Email me if you're interested.
For those that don't really understand the importance of preemptive multitasking (and from reading some comments, there are a few of you out there :-O), let's explain this through an example.
:-)
Consider application (a) that wants to read 128MB of data from the disk and application (b) that wants to read 1KB of data.
Let's say that the disk transfers @ 1MB/sec and let's assume application (a) issues the read 1 second before application (b) is started.
The sequence of calls for each app will look something like this:
1) program calls read
2) read is handled by the top level file system and is handed down to the proper file system
3) the file system calls the block device
4) the block device driver breaks up the request into the maximum block size the device can handle per request (for example 256 sectors for IDE)
5) for every request, the block device sends request to physical drive
6) drive transfers data to host
7) drive indicates 'done'
8) goto 5 until done
9) file system returns
10) read returns
It's important to know that there may be limitations on the number of requests any stage can handle simultaneously. For example, an IDE drive can only handle one request at a time. Some Operating Systems however introduce even tighter restrictions, because for example the block device driver was written, assuming only one request at a time would be allowed.
Take for example an OS where the kernel assures that no more that one request is pending between step 3) and 9).
This would have the following effect on our apps: app (a) is allowed to call step 4) because it is the first request. One second later, app (b) arrives at step 3) and is blocked. It is not allowed to enter step 4) until app (a) is done and passes step 9). Effectively this means that app (b) has to wait for 127 seconds before it gets access to step 4).
Now consider an OS where the file system and drivers can handle multiple requests. It still has to assure that the physical drive receives only one request though, so it permits only access of one app between step 5) and 7). App (a) arrives at step 5) first, so it gets to start sending requests to the drive. One second later, app (b) arrives at step 5) and has to wait for app (a) to finish it's current request to the drive. As soon as this request is done though, app (a) gets to step 8). Now we have both app (a) and app (b) wanting to have access to step 5). Depending on the scheduler either one will be granted access. There's a good change that app (b) will get access, and thus it only had to wait the time it took for app (a) to finish it's outstanding request, which takes max 1/8th of a second (256 sectors = 128KB) in this example.
Btw. you may notice though that there's more likely to be an (expensive) seek introduced by allowing app (b) to interrupt the transfer of app (a)
You can see how moving the 'lock' deeper in to the OS improves responsiveness. I'm not going to start a flame war about which OS is better, all I will say is that MY OS locks steps 5) through 7)
Yes, NT is fully preemptible (except when its holding some very critical locks). However, it is not a real-time kernel, since it makes no guarentees about latency. The stock kernel is fine for soft realtime stuff like audio/video things, but you can't do hard realtime with it. However, there is a product called RTX which claims to make WinNT realtime.
A deep unwavering belief is a sure sign you're missing something...
It's the BSD license. Who can prevent sharing? Even if they wanted to?
karma capped
"RL: You have been becoming well known as the maintainer of a "preemptible kernel patch" for the Linux kernel. How did that situation come about?"
"Love: Well, RL, you start with a group of people who are more than willing to brag that they know who maintains the 'preemptible kernel patch' but feel no need whatever to know what the hell that even is
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Actually, no. I worked at the MIT AI lab during this period, and was in charge of EMACS on the PDP-10 series (for ITS and TOPS-20) after RMS moved on to start the GNU project.
TECO was developed for the PDP series. The PDP-6 and 10 were the systems that ran ITS. EMACS was a package of TECO macros; there were others, RMACS and TMACS for example. RMS and others maintained EMACS, and it became the lead, and eventually it took on a life of its own.
After RMS stopped working on PDP-10 software and was fully engaged on the GNU project, I was in charge of PDP-10 EMACS. There were a variety of other EMACS clones on Unix, small and large, but they all had various extensibility problems (i.e., had to be recompiled) or licensing problems (i.e., you had to buy them). RMS started with one or the other of them and fixed both the licensing and extensibility problems, and everybody knows it all from that point.
RMS did not write TECO, and EMACS was not first on Unix.
I know C-T-L is an interrupt. But DOS and Win9x will lock, often, to the point of not responding to it. I've never seen NT do so, however. As to the bluescreen stuff, the point I'm trying to make is that a BSOD isn't a 'crash,' it's a very obtuse error screen. It's a state that NT throws itself into voluntarily when something goes very very wrong, and that something is almost always a hardware driver. Where screens used to have a "C:\>" burned into the upper left corner, now it's more like "ati.sys" ;-)
Vintage computer games and RPG books available. Email me if you're interested.