| |||||||||||||
|
| |||||||||||||
Con Kolivas returns with a new schedulerCon Kolivas returns with a new schedulerPosted Sep 1, 2009 16:29 UTC (Tue) by kerick (subscriber, #53036)Parent article: Con Kolivas returns with a new scheduler
Am I correct that this scheduler is essentially worthless for any recent ( >=k8 ) AMD and i5/7 due to its' lack of NUMA support? I used to use ck kernels all the time and would be disappointed if he has specifically targetted every processor but the ones I have.
(Log in to post comments)
It says "lower spec" Posted Sep 1, 2009 16:48 UTC (Tue) by ncm (subscriber, #165) [Link]
A scheduler optimized for netbooks and cellphones would not be such a bad thing.
It says "lower spec" Posted Sep 1, 2009 16:52 UTC (Tue) by alex (subscriber, #1355) [Link]
It's not going to get far on cellphones and notebooks without dynamic ticks. Spake the FAQ:
"Configure your kernel with 1000Hz, preempt ON and disable dynamic ticks."
It says "lower spec" Posted Sep 1, 2009 18:34 UTC (Tue) by drag (subscriber, #31333) [Link]
Ya.. he needs to fix that. Otherwise it's very interesting.
Until the Linux kernel gets everything all situated out I think one of the big things that distros can probably do to improve user experience is provide Desktop/Multimedia optimized kernels.
Normally I am a big fan of 'do one thing and get it right before worrying about features' approach, but it's irritating to have to recompile my kernel to get proper responsiveness because the kernels from Debian are all optimized for server use.
$ grep -i preempt /boot/config-2.6.*
I mean, seriously.. How long has Preempt support been around? *cry*
It says "lower spec" Posted Sep 1, 2009 22:30 UTC (Tue) by cortana (subscriber, #24596) [Link]
Has anyone ever filed a bug requesting that these options be enabled?
It says "lower spec" Posted Sep 2, 2009 1:54 UTC (Wed) by N0NB (guest, #3407) [Link]
About a year or two ago I filed a Debian bug report asking for a desktop enabled version of the kernel and essentially received a "thanks but no thanks" closure message. :-/
Desktop Debian = Ubuntu Posted Sep 2, 2009 4:55 UTC (Wed) by zlynx (subscriber, #2285) [Link]
I don't think that I know anyone who runs Debian on the desktop anymore. It seems most run Debian on servers and Ubuntu on the desktop, if they like Debian'ish systems.
Desktop Debian = Ubuntu Posted Sep 2, 2009 5:43 UTC (Wed) by jordanb (subscriber, #45668) [Link]
Try meeting some more people. It's a whole world out there.
Desktop Debian = Ubuntu Posted Sep 2, 2009 7:39 UTC (Wed) by patrick_g (subscriber, #44470) [Link] >>> Try meeting some more people. It's a whole world out there.What is your solution? Recompiling the kernel and lose all the advantages of a distribution kernel? Use a server optimized kernel on your laptop?
Desktop Debian = Ubuntu Posted Sep 2, 2009 13:00 UTC (Wed) by nye (guest, #51576) [Link]
IIRC a couple of years back Con Kolivas had a feature to allow switching the scheduler at runtime, which was deemed a pointless feature and rejected.
Desktop Debian rocks Posted Sep 2, 2009 8:32 UTC (Wed) by man_ls (subscriber, #15091) [Link] Alternatively, try finding out some hard data. For example, Debian's own popularity contest. Taking base admin packages as a baseline (83696), of which over 95% are regularly used, you may find that about 56% use X11 libraries regularly, about half installed desktop-base and 26% use metacity. GNOME is even more popular with 56% having installed gnome-keyring and 32% using it regularly. KDE is less popular with only 23% installing kdebase-data and 10% using any package regularly (interesting, didn't know there was such a disparity with GNOME), while XFCE shows up at 3.7%.You might say that these are servers being admin'd graphically. Let us see typically desktop-y applications: quick browsing shows regular users of Firefox (iceweasel really) at 33%, libgstreamer at 27%, evince at 26%, libgphoto2 and openoffice both at 25%. To put these figures in perspective, Apache is at 44% and Samba at 27%. There are lots of bias in the sample: only utter geeks would install popularity-contest, and only properly connected machines will show up. I would counter that both things pretty much describe Debian's audience. IMHO saying that 50% of Debian users have it as a desktop is a good estimation.
Desktop Debian = Ubuntu Posted Sep 2, 2009 11:54 UTC (Wed) by N0NB (guest, #3407) [Link]
I prefer Debian over Kubuntu as my Kubuntu partition is still infested with GNOME nonsense. At least on Debian I can eliminate the GNOME stuff (or not install it in the first place) without breaking the distribution. That said, right now desktop effects with compositing are working much better in Karmic than Sid, both are up-to-date.
Desktop Debian = Ubuntu Posted Sep 2, 2009 20:41 UTC (Wed) by branden (guest, #7029) [Link]
"I don't think that I know anyone who runs Debian on the desktop anymore."
Nice to meet you. I'm Branden.
Desktop Debian = Ubuntu Posted Sep 2, 2009 20:47 UTC (Wed) by zlynx (subscriber, #2285) [Link]
But do I know you?
I mean, when I said it, I meant people I actually know in person and I know what they're running.
Now, as I don't make a habit of going around asking people if they're running Ubuntu or Debian or what, my sample size is about 5 people.
One of those I know used to run a Debian laptop and I *think* he is running Ubuntu now but possibly not. I know the other 4 are running Ubuntu.
Desktop Debian = Ubuntu Posted Sep 2, 2009 21:01 UTC (Wed) by alex (subscriber, #1355) [Link]
Hey I suggested my other half install Debian on her old laptop as she wanted experiment with free software. I was slightly worried she would have issues with the wireless but it all installed and ran fine. I think Debian makes a fantastic desktop OS if your not concerned about the latest whizz bang graphics effects or media players. It's stable and lightweight and very developer friendly.
Desktop Debian = Ubuntu Posted Sep 3, 2009 13:10 UTC (Thu) by nix (subscriber, #2304) [Link]
Former DPLs need not apply ;}
(of course I'm running Debian on the desktop too, and adminning it remotely for my mum, who's in the same boat, and all she wants is something that Just Works and isn't virally infestable...)
It says "lower spec" Posted Sep 2, 2009 9:45 UTC (Wed) by cortana (subscriber, #24596) [Link]
Indeed, I should have searched before I posted.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311185 -- as of 2007, more testing for stability required; 'realtime patch' also mentioned, I have no idea if that still exists for current kernels or whether it's been merged
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496871 -- request for benchmarks (along with "please stop waffling", great way to interact with users, kernel team...)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539209 -- filed recently (July 09) but no reply
Does anyone actually have any benchmarks demonstrating the efficacy of the pre-emption options?
It says "lower spec" Posted Sep 2, 2009 16:57 UTC (Wed) by drag (subscriber, #31333) [Link]
It's hard to benchmark.
Technically a preemptive kernel will be slower then a non-preemptive one in most complex benchmarks. This is because going from process to process rapidly means more context changes and thus you lose out on cpu memory cache and all that.
But since the desktop is idle 99% of the time then it's easy to make the justification that it's worth it to say "Ya it takes a couple milliseconds longer to open a webpage, but this way I can do it without getting my music interrupted or keep my game/movie framerate high."
Intel developed a tool called latencytop that can be used to identify processes that are hogging the system and can causing usability or deterministic time problems.
Remember the point to having 'realtime' performance is not to make things _faster_ per say.. it's to make things more deterministic. So you know how long it will take to get something done. On a very hard-ish realtime system you can say "It's going to take a maximum of 30msec to accomplish X task" and you can depend on it. On a typical Linux server system it may take 5-10msec most of the time to do the same amount of work, but if something else is going on then it may take 500msec or more; You can't tell how long something is going to take, even though it's likely to get done faster on average.
This sort of trade off is what you need to keep your video smooth, games fast, music interrupt free, scientific measurements accurate, robotic assembly machines from zapping the wrong parts of a chassis, etc etc. Anytime you need to interact with the real world....
So ya.. benchmarks are very difficult and are skirting the issue.
It says "lower spec" Posted Sep 2, 2009 13:41 UTC (Wed) by guus (subscriber, #41608) [Link]
Notice the line directly above the note about configuring for 1000Hz and disabling tickless:
"THESE ARE OPTIONAL FOR LOWEST LATENCY. YOU DO NOT NEED THESE!"
So with tickless kernels, you get a slightly less low latency, but it would work fine.
It says "lower spec" Posted Sep 2, 2009 15:12 UTC (Wed) by rsidd (subscriber, #2582) [Link]
There is no changelog to the FAQ so I'm not sure, but I think that line is new. Ditto for the NUMA line. I'm sure Con Kolivas uses reasonably contemporary machines, even if he disdains optimising for machines with 4096 CPUs.
Con Kolivas returns with a new scheduler Posted Sep 1, 2009 17:01 UTC (Tue) by intgr (subscriber, #39733) [Link]
I can't see why it wouldn't work well on a typical single-processor multi-core k8 or i7 chip. One CPU package only contains a single memory controller, so all the memory is uniform.
Am I missing something here?
Con Kolivas returns with a new scheduler Posted Sep 2, 2009 1:52 UTC (Wed) by lethal (guest, #36121) [Link]
Not quite so simple. There are plenty of single-CPU systems with NUMA characteristics. Memory-only NUMA nodes are becoming fairly common place, both in commodity and especially in embedded platforms. Indeed, many Linux-based cellphones are shipping with NUMA enabled by default today -- and more recently also on the microcontroller side, albeit without page migration.
Any scheduler that fails to take issues like NUMA, SMP, dynamic ticks, etc. in to account while claiming to be "looking forward" will remain nothing but a toy scheduler for an insular workload. All of these have effectively become common place, to the extent that simply discounting them out of hand reads a lot more like looking back than forward, especially given that many low memory systems depend on all of these capabilities.
In any event there is anything wrong with out of tree pet projects, especially for trying out new things. If this new scheduler improves things for certain workloads, then hopefully someone will step up to work with upstream and improve things there incrementally.
Con Kolivas returns with a new scheduler Posted Sep 2, 2009 15:01 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Any scheduler that fails to take issues like NUMA, SMP, dynamic ticks, etc. in to account while claiming to be "looking forward" will remain nothing but a toy scheduler for an insular workload I believe what Con meant by "forward looking" when he described his scheduler is that it doesn't adjust time slices based on recent history (ie. "backward looking") of a task's run/sleep behavior. From Con's post: I feel the scheduler should being forward looking only (not calculating sleep) His explicit rejection of NUMA and high-CPU-count machines makes it clear he's only really interested in what constitutes a "typical desktop" today. From Con's post: Machines with NUMA will probably suck a lot with this because it pays no deference to locality of the NUMA nodes when deciding what cpu to use. I imagine the loss of raw MIPS due to lack of NUMA awareness on even a high end personal desktop isn't too great either. Modern desktop machines are NUMA, but they're fairly mild NUMA from what I gather. (Why else would my Opteron's BIOS offer me the option to interleave my memory across all nodes? That'd be disaster on a more extreme NUMA architecture, but it supposedly provides a performance boost on older non-NUMA-aware OSes.) In fact, I'd further imagine the average user would trade actual increased responsiveness for a few % loss on peak benchmark performance numbers. At the very least, I imagine Con might. :-) All that said, the place where I experience the greatest loss in responsiveness is Firefox, not the rest of my desktop, and Firefox is just a single thread at the moment. Con, can you come fix Firefox? ;-)
Con Kolivas returns with a new scheduler Posted Sep 3, 2009 2:37 UTC (Thu) by charris (subscriber, #13263) [Link]
I find that gnome terminals will ignore my bluetooth keyboard for up to several seconds. I don't know if this is because of the bluetooth driver, X, or the scheduler, but it sure is annoying. And this on a 3GHz quad core system.
Con Kolivas returns with a new scheduler Posted Sep 3, 2009 13:15 UTC (Thu) by nix (subscriber, #2304) [Link]
It's certainly not the bluetooth driver or X, because I see this on the console of a one-die four-core Nehalem (Core i7) with no X running at all and a PS/2 keyboard. It's lightly loaded by these standards (load average 8.1, which as it's hyperthreaded is pretty much equivalent to 'everything loaded but not much'), and surely isn't swapping (12Gb RAM, 6Gb *free*, not even used for cache). Yet I see three-second pauses in keyboard activity.
I'll turn on latencytop and see what it says, but the pauses are fairly rare so it might be interesting to interpret.
Con Kolivas returns with a new scheduler Posted Sep 3, 2009 13:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
I've only gotten multi-second pauses like that when I had a hard drive going bad, or I was swapping rather furiously.
With that much RAM, I wonder if VM housekeeping itself could cause such lags. 12Gb would have 3 million 4K pages. If you are running at 3GHz and did something that averaged 3000 cycles/page across all 3 million pages, that's 3 seconds.
Con Kolivas returns with a new scheduler Posted Sep 3, 2009 17:31 UTC (Thu) by charris (subscriber, #13263) [Link]
I also see "stuck" keys where a letter will repeat until the buffer is full. I see this on various hardware with various keyboards, so it isn't an actual stuck key. Do you see that also?
Con Kolivas returns with a new scheduler Posted Sep 3, 2009 18:14 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
That sounds more like a dropped event somewhere such as dropped interrupt or the like. I haven't experienced that on any Linux box so far.
Stuck keys. Posted Sep 4, 2009 2:47 UTC (Fri) by ncm (subscriber, #165) [Link]
I've seen on 2.6.29. Unplugging and re-plugging the (USB) keyboard didn't fix it. Only switching to console and back did it. I was inclined to blame the new X input system. It hasn't happened since I upgraded X and also went to 2.6.30, so who knows?
Input pauses Posted Sep 4, 2009 4:09 UTC (Fri) by ncm (subscriber, #165) [Link]
I see input-event stalls for up to six seconds in Firefox (Debian Iceweasel, actually), routinely. To get it I just have to leave it running for a week or so, with a few dozen pages, some of which self-update.
I doubt the scheduler would help; during those six seconds, one CPU is pegged at 100%. This is with nothing swapped. I suspect it's doing a garbage collection scan during each pause. I'd welcome suggestions for how to discover what's going on.
Google Chrome is coming along too slowly.
Input pauses Posted Sep 4, 2009 4:32 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]
I know Firefox's stalls are Firefox's fault, not the Linux scheduler's. I was begging Con to do interactivity work on Firefox. ;-)
(As in, contribute to the Mozilla team.)
Input pauses Posted Sep 4, 2009 8:17 UTC (Fri) by Cato (subscriber, #7643) [Link]
I've had these pauses for several seconds sometimes in Firefox 3.5.2, but they seem to be associated with large writes e.g. un-tarring a huge file at the same time - so I suspect it's the well known "Firefox 3.0 + ext3 + fsync" issue, reported in http://lwn.net/Articles/284126/ and elsewhere.
Con Kolivas returns with a new scheduler Posted Sep 1, 2009 17:51 UTC (Tue) by Velmont (subscriber, #46433) [Link] Worthless? In the FAQ it seems pretty reasonable. Would be fun to try. I also used -ck kernels in the good old days For years we've been doing our workloads on linux to have more work than we had CPUs because we thought that the "jobservers" were limited in their ability to utilise the CPUs effectively (so we did make -j6 or more on a quad core machine for example). This scheduler proves that the jobservers weren't at fault at all, because make -j4 on a quad core machine with BFS is faster than *any* choice of job numbers on CFS.
Con Kolivas returns with a new scheduler Posted Sep 7, 2009 10:09 UTC (Mon) by jlokier (subscriber, #52227) [Link]
The real reason we used to use "make -j MORE_THAN_NR_CPUS" was to get useful work done when a process waits on I/O. Con's scheduler doesn't help with that: if gcc foo.c needs to read foo.c from disk, you must have more jobs than CPUs, or you have an idle CPU.
What's changed is nowadays most of us have enough RAM to keep the whole kernel source and object files in cache, so there's no I/O delay after the first compile of the day.
I'm surprised Con's scheduler compiles more quickly than CFS, and that has to be worth looking into.
Con Kolivas returns with a new scheduler Posted Sep 4, 2009 9:31 UTC (Fri) by DavidG (guest, #60628) [Link]
FWIW: for AMD, only Opterons have NUMA and AFAIK Intel i7 don't have NUMA either.
So you're save to use BFS.
Con Kolivas returns with a new scheduler Posted Sep 5, 2009 3:28 UTC (Sat) by realnc (guest, #60393) [Link] "BIG NUMA machines will probably suck a lot with this because it pays no deference to locality of the NUMA nodes when deciding what cpu to use. It just keeps them all busy. The so-called "light NUMA" that constitutes commodity hardware these days seems to really like BFS." The point is that big NUMA machines aren't used for Desktops ;)
|
|
||||||||||||