just in case the server is down - there's the interview I did. But please do stop by www.tinyminds.org once the server is back up, it's a great little newbies site.
Robert M. Love Interview by Lovechild
Want to know what's in store for you, the Linux desktop user, with the upcoming kernel 2.6, well have no fear, TinyMinds brings you an early christmas present: an interview with Robert M. Love, kernel hacker extraordinare, student and all round nice guy.
TM:
First of all, I'd like to thank you for taking the time to answer a few questions for our members.
RML: You are welcome.
TM:
Most of us only know you as the guy that brought us the preemptive kernel patch and all it's niceness, please enlighten us a bit on the real Robert Love?
RML:
The real Robert Love enjoys the finer things in life, such as Cheetos.
I am a Mathematics and CS student at the University of Florida. Born in
Southern Florida and now in Central Florida. Not a big fan of Florida
at all, though.
I work for MontaVista Software, the embedded Linux company, as a kernel
engineer. I primarily work on scheduling, performance, and real-time
kernel projects.
I enjoy photography, good music, and good food.
TM:
How did you get involved with Kernel hacking?
RML:
I always found operating systems interesting and Linux provided a rare
but welcome opportunity to get involved. I started following the lists,
reading books, and perusing the source. I aspired.
I started with bug fixes and driver updates. Then I jumped in head
first.
TM:
But why the Linux kernel, there are many kernel projects out there, fx. HURD and the BSDs - What attracted you to this kernel.
RML:
I had been using Linux for awhile, so it was a natural progression for
me.
TM:
On to the actual questions, as Tinyminds.org is primarily a desktop user Linux site we were wondering if you would tell us a bit about the changes the desktop user can expect in the upcoming kernel 2.6?
RML:
Desktop users can expect a bit in 2.6, which is somewhat surprising as
the goals of 2.5 were primarily to improve scalability and reduce
bottlenecks in large machines.
First off, of course, there is the preemptive kernel. The preemptive
kernel makes the kernel schedule preemptively like user-space, as
opposed to schedule cooperatively. This improves process response by
allowing a freshly woken up process to immediately preempt the running
task, even if the task is inside the kernel.
Next, the new scheduler is important. Although the primary features of
the O(1) scheduler are not important to desktop users - since desktop
users typically have only a handful of runnable processes and only one
or two processors - the interactivity estimator in the O(1) scheduler
can greatly improve system feel. For example, during a large multi-job
compile in X it is very possible for the system to lose responsiveness
as the compilers hog the processor. With the O(1) scheduler, the
interactivity estimator can ensure that your "interactive" tasks receive
the processor's time.
The new I/O scheduler has a couple improvements that benefit
interactivity. The I/O scheduler is the part of the kernel which
decides which blocks to write out or read in from disk. The kernel
orders such block requests to try to keep drive access linear - so the
drive head is not hoping around like mad. In 2.5 we have the new
"deadline I/O scheduler" which replaces the old "elevator". The first
benefit from the new I/O scheduler is it enforces deadlines. This
insures that no request is starved. The second benefit is a
preferential treatment given to reads over writes. This solves the
issue of writes starving reads. In applications, pending reads
generally stall the program until they are serviced and contribute to
process latency. Pending writes, on the other hand, do not matter one
bit to the program. Both of these features improve desktop performance.
Finally, we have the new VM and block I/O layer. They have both been
redesigned and greatly simplified. They work together a lot better now,
and it is much easier to saturate the disk. These changes have two
large ramifications for desktop users: better fairness and improved
performance in corner cases. This is a big change over 2.4, which was
not all that fair. In 2.5, a lot of work has gone into insuring that
multiple tasks all make equal progress when the machine is under load.
Swap out performance is improved. Tasks are not blocked for ludicrous
amounts of time.
In short, 2.6 should be "nicer" on the desktop but for normal machines
with normal workloads the improvement will not be huge since 2.4 was not
that bad to begin with. But 2.6 will certainly be excellent.
TM:
Now your preemptive kernel patch has become very popular with desktop users, would you mind giving us a quick walk through on how it works?
RML:
Sure. Previously, the kernel was not preemptive. It was scheduled
cooperatively. This meant that process code in the kernel (executing a
system call, servicing a page fault, etc.) and kernel threads ran until
they explicitly give up the processor and caused a reschedule. This can
cause latency and poor response if a reschedule is pending and cannot
occur until the current process exits from the kernel.
Let us look at an example. Pretend there are two processes on the
system. The first is a background job, like a compile. The second is
the great text editor, vim. The compiler is running while vim is
blocked waiting for keyboard input (as usual). Assume the compiler is
in the kernel executing a system call. Next, the user types into vim.
This causes an interrupt from the keyboard controller, which copies the
new data into a buffer for vim. Then vim is woken up and hopefully
rescheduled. Unfortunately, vim cannot run until the compiler exits
from the kernel.
This delay contributes to scheduling latency (the difference in time
between wanting to run and actually running). If it is noticeable,
users get cranky. The problem is bigger for real-time applications,
because they need minimal latency. It is not good if a lower priority
process can prevent a higher priority process from running.
So now, with a preemptive kernel, when the keyboard interrupt wakes up
vim, vim can run immediately. Soon as the interrupt returns, the kernel
notices a process was woken up and can invoke the scheduler.
Fundamentally this is a simple change but it requires a large-scale
reimplementation of code to protect concurrency. Thankfully, the
kernel's SMP spin locks already provide the large majority of this
protection. So these spin locks are used as markers of where to
temporarily disable preemption, to avoid mangling shared data. It works
and everyone is happy.
TM:
Besides the preemptive kernel patches, what else have you been working on?
RML:
A bit of scheduler work. I work on bugs and issues as they arise and
helped with some of the initial work. I wrote the processor affinity
system calls, which are now in 2.5. I did a hint-based scheduling call
and most recently wrote a small patch for allowing run-time tuning of
the scheduler via procfs or sysctl.
I like to pretend I am a VM hacker. I ported the VM strict overcommit
infrastructure from 2.4-ac to 2.5, and that is now merged. I try to
send useful cleanups or improvements to Andrew Morton. For example, I
did a low latency zap_page_range() implementation.
I also wrote and maintain schedutils ,
the Linux scheduler utility package. And I maintain procps
- the package that contains ps, top,
vmstat, free, etc. - with Rik van Riel.
TM:
Recently it has become tradition for ConTest result to be posted on lkml. I understand you have played a role in this (along with Andrew Morton and Con Kolivas). Why is has this testsuit been so well received when kernel hackers normally flame benchmarking suites in general, and what impact will ConTest have on further fine tuning of the kernel?
RML:
Contest is a very unique benchmark in that it measures system
responsiveness. More importantly, it is a great tool for measuring
fairness. Contest has been a big help in enabling us (and by 'us' I
mean very much Andrew) in improving the performance of doing multiple
things at the same time.
I guess its beauty lies in its simplicity. Contest simply times a
kernel compile - first, by itself, then under various loads. This helps
us understand fairness issues and insure the machine stays usable under
load. Contest is a significant reason for the fairness and
responsiveness seen in 2.5.
But I do not think kernel developers normally have an issue with
benchmarks. They are very useful for tuning and regression testing.
They just are not all that matters.
TM:
Care to guess at what marvels we will see in the next development cycle (kernel 2.7)?
RML:
Whatever the developers find interesting. Probably some improved NUMA
support. Perhaps a couple VM features to solves issues discovered
during 2.6.
Easier is to say what we need: tty layer rewrite and SCSI layer
rewrite. A unified disk layer would be very nice.
TM:
What would a tty layer rewrite and SCSI layer rewrite grants us, meaning is the current one just really suboptimal ?
RML:
The current layers work, but are just suboptimal. More specifically,
they are not clean. Perhaps even gross.
The tty layer is old, poorly understood code. It may contain races or
hard to find bugs. It is strongly wed to the BKL.
The SCSI layer is not terrible, but it needs some work. SCSI drivers
have to implement far too much code on their own. The SCSI layer needs
to be cleaned up, generalized, and receive a face lift.
Boring work, unfortunately.
TM:
I was thinking more in the lines of when(if ever) will we see stuff like Supermount in the mainline kernel, it's provides a much needed feature for desktop use. Personally I think we need features like that to make Linux more useable for migrating users from say Windows or Mac.
RML:
I do not know the future of supermount. I agree its a useful feature
for users migrating from stateless mount systems like Windows. I think
it has its place in vendor kernels, at least.
TM:
What's your take on Linux' future on the desktop market?
RML:
I wish I could say "well our technology is superior so of course Linux
can capture the market". But it does not work like that, because we are
facing a monopoly. We are attacking a market that historically no one
has made significant progress in.
I think we are better than Windows. I do not believe anyone can look at
the state of the current GNOME or KDE desktop and tell me that the
Windows desktop is superior. The UI decisions made in the current GNOME
releases are excellent. It is a beautiful and well-thought out
implementation. For example, Red Hat 8.0 is quite impressive.
We are missing applications, though. Windows has a very wide array of
programs, including important titles like Microsoft Office. While I
think some Linux desktop applications are superior (Mozilla) or at least
equal (Evolution), we need more. I started using Open Office recently
and I was very surprised how complete it was. Application availability
is our weak spot, but we can do it.
Oh, and of course our kernel is far superior;)
TM:
Again thank you for all your hard work on the Linux kernel and thank you for taking time away from hacking the kernel to talk to us. From all of Tinyminds.org, a merry Christmas to you and your loved ones.
RML:
Thanks and the same to you and yours.
Here are soem links for ya!
www.freeos.com
www.osopinion.com
www.osnews.com
Sounds like a good project, but since I whole heartedly believe in Free Software I'm not going to be a great help for you. Though I believe that every thing can take some critic..
Good Luck !
Slashdot Mirror
LOL.... voted (Score:0, Offtopic) Yet it is the topic.... this is so much fun.. yes yes, I know, now I'll become (-1, Flamebait)
it was a nasty cut and paste job, earn some karma.. clean it up.. I was just trying to be nice.
just in case the server is down - there's the interview I did. But please do stop by www.tinyminds.org once the server is back up, it's a great little newbies site. Robert M. Love Interview by Lovechild Want to know what's in store for you, the Linux desktop user, with the upcoming kernel 2.6, well have no fear, TinyMinds brings you an early christmas present: an interview with Robert M. Love, kernel hacker extraordinare, student and all round nice guy. TM: First of all, I'd like to thank you for taking the time to answer a few questions for our members. RML: You are welcome. TM: Most of us only know you as the guy that brought us the preemptive kernel patch and all it's niceness, please enlighten us a bit on the real Robert Love? RML: The real Robert Love enjoys the finer things in life, such as Cheetos. I am a Mathematics and CS student at the University of Florida. Born in Southern Florida and now in Central Florida. Not a big fan of Florida at all, though. I work for MontaVista Software, the embedded Linux company, as a kernel engineer. I primarily work on scheduling, performance, and real-time kernel projects. I enjoy photography, good music, and good food. TM: How did you get involved with Kernel hacking? RML: I always found operating systems interesting and Linux provided a rare but welcome opportunity to get involved. I started following the lists, reading books, and perusing the source. I aspired. I started with bug fixes and driver updates. Then I jumped in head first. TM: But why the Linux kernel, there are many kernel projects out there, fx. HURD and the BSDs - What attracted you to this kernel. RML: I had been using Linux for awhile, so it was a natural progression for me. TM: On to the actual questions, as Tinyminds.org is primarily a desktop user Linux site we were wondering if you would tell us a bit about the changes the desktop user can expect in the upcoming kernel 2.6? RML: Desktop users can expect a bit in 2.6, which is somewhat surprising as the goals of 2.5 were primarily to improve scalability and reduce bottlenecks in large machines. First off, of course, there is the preemptive kernel. The preemptive kernel makes the kernel schedule preemptively like user-space, as opposed to schedule cooperatively. This improves process response by allowing a freshly woken up process to immediately preempt the running task, even if the task is inside the kernel. Next, the new scheduler is important. Although the primary features of the O(1) scheduler are not important to desktop users - since desktop users typically have only a handful of runnable processes and only one or two processors - the interactivity estimator in the O(1) scheduler can greatly improve system feel. For example, during a large multi-job compile in X it is very possible for the system to lose responsiveness as the compilers hog the processor. With the O(1) scheduler, the interactivity estimator can ensure that your "interactive" tasks receive the processor's time. The new I/O scheduler has a couple improvements that benefit interactivity. The I/O scheduler is the part of the kernel which decides which blocks to write out or read in from disk. The kernel orders such block requests to try to keep drive access linear - so the drive head is not hoping around like mad. In 2.5 we have the new "deadline I/O scheduler" which replaces the old "elevator". The first benefit from the new I/O scheduler is it enforces deadlines. This insures that no request is starved. The second benefit is a preferential treatment given to reads over writes. This solves the issue of writes starving reads. In applications, pending reads generally stall the program until they are serviced and contribute to process latency. Pending writes, on the other hand, do not matter one bit to the program. Both of these features improve desktop performance. Finally, we have the new VM and block I/O layer. They have both been redesigned and greatly simplified. They work together a lot better now, and it is much easier to saturate the disk. These changes have two large ramifications for desktop users: better fairness and improved performance in corner cases. This is a big change over 2.4, which was not all that fair. In 2.5, a lot of work has gone into insuring that multiple tasks all make equal progress when the machine is under load. Swap out performance is improved. Tasks are not blocked for ludicrous amounts of time. In short, 2.6 should be "nicer" on the desktop but for normal machines with normal workloads the improvement will not be huge since 2.4 was not that bad to begin with. But 2.6 will certainly be excellent. TM: Now your preemptive kernel patch has become very popular with desktop users, would you mind giving us a quick walk through on how it works? RML: Sure. Previously, the kernel was not preemptive. It was scheduled cooperatively. This meant that process code in the kernel (executing a system call, servicing a page fault, etc.) and kernel threads ran until they explicitly give up the processor and caused a reschedule. This can cause latency and poor response if a reschedule is pending and cannot occur until the current process exits from the kernel. Let us look at an example. Pretend there are two processes on the system. The first is a background job, like a compile. The second is the great text editor, vim. The compiler is running while vim is blocked waiting for keyboard input (as usual). Assume the compiler is in the kernel executing a system call. Next, the user types into vim. This causes an interrupt from the keyboard controller, which copies the new data into a buffer for vim. Then vim is woken up and hopefully rescheduled. Unfortunately, vim cannot run until the compiler exits from the kernel. This delay contributes to scheduling latency (the difference in time between wanting to run and actually running). If it is noticeable, users get cranky. The problem is bigger for real-time applications, because they need minimal latency. It is not good if a lower priority process can prevent a higher priority process from running. So now, with a preemptive kernel, when the keyboard interrupt wakes up vim, vim can run immediately. Soon as the interrupt returns, the kernel notices a process was woken up and can invoke the scheduler. Fundamentally this is a simple change but it requires a large-scale reimplementation of code to protect concurrency. Thankfully, the kernel's SMP spin locks already provide the large majority of this protection. So these spin locks are used as markers of where to temporarily disable preemption, to avoid mangling shared data. It works and everyone is happy. TM: Besides the preemptive kernel patches, what else have you been working on? RML: A bit of scheduler work. I work on bugs and issues as they arise and helped with some of the initial work. I wrote the processor affinity system calls, which are now in 2.5. I did a hint-based scheduling call and most recently wrote a small patch for allowing run-time tuning of the scheduler via procfs or sysctl. I like to pretend I am a VM hacker. I ported the VM strict overcommit infrastructure from 2.4-ac to 2.5, and that is now merged. I try to send useful cleanups or improvements to Andrew Morton. For example, I did a low latency zap_page_range() implementation. I also wrote and maintain schedutils , the Linux scheduler utility package. And I maintain procps - the package that contains ps, top, vmstat, free, etc. - with Rik van Riel. TM: Recently it has become tradition for ConTest result to be posted on lkml. I understand you have played a role in this (along with Andrew Morton and Con Kolivas). Why is has this testsuit been so well received when kernel hackers normally flame benchmarking suites in general, and what impact will ConTest have on further fine tuning of the kernel? RML: Contest is a very unique benchmark in that it measures system responsiveness. More importantly, it is a great tool for measuring fairness. Contest has been a big help in enabling us (and by 'us' I mean very much Andrew) in improving the performance of doing multiple things at the same time. I guess its beauty lies in its simplicity. Contest simply times a kernel compile - first, by itself, then under various loads. This helps us understand fairness issues and insure the machine stays usable under load. Contest is a significant reason for the fairness and responsiveness seen in 2.5. But I do not think kernel developers normally have an issue with benchmarks. They are very useful for tuning and regression testing. They just are not all that matters. TM: Care to guess at what marvels we will see in the next development cycle (kernel 2.7)? RML: Whatever the developers find interesting. Probably some improved NUMA support. Perhaps a couple VM features to solves issues discovered during 2.6. Easier is to say what we need: tty layer rewrite and SCSI layer rewrite. A unified disk layer would be very nice. TM: What would a tty layer rewrite and SCSI layer rewrite grants us, meaning is the current one just really suboptimal ? RML: The current layers work, but are just suboptimal. More specifically, they are not clean. Perhaps even gross. The tty layer is old, poorly understood code. It may contain races or hard to find bugs. It is strongly wed to the BKL. The SCSI layer is not terrible, but it needs some work. SCSI drivers have to implement far too much code on their own. The SCSI layer needs to be cleaned up, generalized, and receive a face lift. Boring work, unfortunately. TM: I was thinking more in the lines of when(if ever) will we see stuff like Supermount in the mainline kernel, it's provides a much needed feature for desktop use. Personally I think we need features like that to make Linux more useable for migrating users from say Windows or Mac. RML: I do not know the future of supermount. I agree its a useful feature for users migrating from stateless mount systems like Windows. I think it has its place in vendor kernels, at least. TM: What's your take on Linux' future on the desktop market? RML: I wish I could say "well our technology is superior so of course Linux can capture the market". But it does not work like that, because we are facing a monopoly. We are attacking a market that historically no one has made significant progress in. I think we are better than Windows. I do not believe anyone can look at the state of the current GNOME or KDE desktop and tell me that the Windows desktop is superior. The UI decisions made in the current GNOME releases are excellent. It is a beautiful and well-thought out implementation. For example, Red Hat 8.0 is quite impressive. We are missing applications, though. Windows has a very wide array of programs, including important titles like Microsoft Office. While I think some Linux desktop applications are superior (Mozilla) or at least equal (Evolution), we need more. I started using Open Office recently and I was very surprised how complete it was. Application availability is our weak spot, but we can do it. Oh, and of course our kernel is far superior ;)
TM:
Again thank you for all your hard work on the Linux kernel and thank you for taking time away from hacking the kernel to talk to us. From all of Tinyminds.org, a merry Christmas to you and your loved ones.
RML:
Thanks and the same to you and yours.
Here are soem links for ya! www.freeos.com www.osopinion.com www.osnews.com Sounds like a good project, but since I whole heartedly believe in Free Software I'm not going to be a great help for you. Though I believe that every thing can take some critic.. Good Luck !