CPU scheduling is just fine for most of the enduser workflows. None of the end users are going to compile kernel and watch a video parallely. And these days, most of the common tasks are done in a smart phone and not even with a pc. I tried running a Kernel with ConKollivas patch and did not find any improvements in my laptop. I don't expect to see much improvement with this patch either.
Bad user space algorithms, improper I/O, poor data structures are the primary reason why end user applications suck and the desktop appears poorly-responsive. Just because we change the scheduler, Firefox is not going to start as fast as Chrome overnight. We need to improve our user space applications if Linux on desktop has to be more responsive.
Michael Meeks's iogrind work has shown us that sqlite writes all-over the disk and fixing that may help many applications start faster (or until Intel gives us all free SSDs ;)) Also, I got reminded of an excellent slide from Federico's GUADEC talk.
So, A is I/O and B is CPU. So, until I/O is improved I will be skeptical if a CPU patch can create a miracle for desktop user experience :-)
Please note that I am not trying to degrade the efforts of the person who has done the Kernel patch. I believe it is awesome to work on TTY layer and get praise from Linus himself. But I just don't believe that it will cause miracle for endusers. I will be happy to see me go wrong in this case.
14 comments:
Check out the videos on Phoronix. It is a pretty obvious improvement.
Totally agreed. Today its optimizing cpu scheduling. Tomorrow it may be increasing the computing hardware, while the actual bottleneck is the sucky application layer code.
One of the problems this patch may be helping with is that I/O bound processes *do* influence CPU bound processes.
@will_in_wi : Only if you launch all your applications from different terminals, they will all belong to a different cgroup and hence wont starve CPU. If you launch from GNOME/KDE menus, the applications will not have TTY value and will have the same old problems.
Look into Lennart Poettering's mail in LKML on the same thread.
"None of the end users are going to compile kernel and watch a video parallely"
Not true... I do that all the time, not just the kernel, since I run gentoo I care about my desktop being responsive when stuff is compiling in the background.
Although you are right that IO is a big problem, however if you're doing a big compile and watching video at the same time that's likely to stress IO scheduling as well as CPU scheduling (try compiling firefox or OpenOffice/LibreOffice in the background while watching a HD video off your hard drive, that should seriously stress both IO and CPU scheduling, make sure to run at least as many make jobes as you have CPU cores)
spudd86: I am sorry I should've mentioned "none of the typical home users (not software engineers)" :-) I agree that this patch will be useful for some workflows, but I wont call it a miracle for my uncle type users.
Actually a kernel improvement could make Firefox and Chrome startup much(ie 2x or more) faster. Startup is one area where huge apps are completely dependent on the kernel + toolchain.
Here is a sample blog post http://blog.mozilla.com/tglek/2010/04/05/linux-how-to-make-startup-suck-less-and-reduce-memory-usage/
Regarding sqlite writing all over the disk. I completely agree, the sqlite IO story sucks. I did fix the writing-all-over-disk issue in sqlite/firefox. See http://blog.mozilla.com/tglek/2010/09/07/fighting-fragmentation-sqlite/ for the description of the problem. Careful preallocation solves that.
So I agree with your general statement that IO matters far more than CPU, but there are significant optimizations left in optimizing toolchain+kernel interactions that will make Firefox startup MUCH faster than any algorithmic changes :) Some of them are coming in gcc 4.6.
Tara: Thanks. They are some nice real links. I for one have noticed the speed differences in FF 4 and thanks for all the work. I still use chrome primarily though bcos of the startup speed and I miss my dearly FF badly (addons, better unicode rendering etc.) May be I will try to switch to it soon. Please blog about the new gcc improvements you mentioned, if you have time so that other apps. could also use it. Thanks for visiting by and the comments.
I think that the patch is a good thing. Scheduling is not about performance and profiling in a lot of ways does not solve it (it does but as you noticed, is practically imperceptible). Anyway, if you would work on an Atom based CPU, where the constrained CPU will make the difference, you will likely see the difference of scheduler.
Just for myself I'm fully impressed on FF 4.0 performance, but I've started it on a low end machine, and was really slower than IE6 based Maxton with XP. So my affraid is that schedule matter when CPU is the bottleneck, and this matter on low end. I also tend to compress hard drive folders (on NTFS) on places I've got a lot of reads because I like to trade disk accesses to IO, but I do think that are desktop schedulers (in Windows 2K to up you can pick "Background services" priority and you will see a different profile from the regular "Foreground applications": try games, compilations. Compilations will work much better with background services, when games will lag sometimes even on a high end machine.
From my experience, Don't ever underestimate the affect of L1 ICache misses. Unlike a DCache miss the CPU can't do out of order execution and hide the penalty for a few clock cycles. I've worked on programs with a 32KB ICache, where the program goes through a big 33KB loop of code in its hotpath. That results in almost every 8th opcode as a cache miss. Once the code was optimized to 32KB, the performance boost was over 5x
This patch has to be a bad joke.
I mean, scheduling according to TTYs? How many users was this patch written for?
Oh yeah, of course, since it gives improvement for Phoronix users, they could make a video of it that shows that OH MY GOD YOU CAN BUILD YOUR KERNEL WHILE WATCHING VIDEO.
Way to go.
FWIW, I think Meeks stopped work on iogrind after realizing it would be made totally irrelevant once SSDs become more common.
I'm using this patch already. Improves responsiveness in daily work a bit, but the main issue still remains I/O for me. Unpacking big files makes my computer freeze for seconds, so ...
What you say is true. BUT, in my case the improvement is tremendous.
If you have a SSD disk and a good modern processor, the patch makes wounder when working with big files and processor intensive tasks such as compiling. And I love to watch a movie / TV-serie or listen to music while working =)
Post a Comment