| |||||||||||||
|
| |||||||||||||
Con Kolivas returns with a new schedulerCon Kolivas returns with a new schedulerPosted Sep 4, 2009 11:10 UTC (Fri) by realnc (guest, #60393)Parent article: Con Kolivas returns with a new scheduler
I've just installed a bfs (204) patched kernel on my Core 2 Duo. I fired up LMMS and started a CPU hungry project and there's not a single sound skip/pop/crackle. Smooth. It was giving lots of sound artifacts (due to under-runs) before. At the same time I started playing notes in the Fluidsynth synthesizer (utilizing a 1.8GB sound font!), and there's virtually no lag between the key press and when the note actually plays anymore. Then I started a kernel build (-j2), fired up mplayer on a 1080p HD video, and continued working in LMMS. Still smooth. That was totally killing LMMS before (too much lag). I felt like I was using the MS Windows version of LMMS. I now realize that the current scheduler totally sucks for Desktops. IMHO, what Desktop Linux needs desperately right now are more people like Kolivas. Dude, if you're reading this: thank you. I hope people will contribute to BFS. But I guess the kernel devs will not even take a look at it since it doesn't "scale". (The sound cracks/pops and lag in my music authoring tool won't "scale" either, but it seems they don't care very much; you see, LMMS is not MySQL. A 1% regression there and they start running to fix it. But who cares about me making music on Linux, right?)
(Log in to post comments)
Con Kolivas returns with a new scheduler Posted Sep 6, 2009 10:50 UTC (Sun) by kragil (guest, #34373) [Link]
I have to agree completely!
On my EeePC Linux (Fedora) hangs, skips and freezes. Really annoying. XP and OSX86 don't. I really wish some Netbook distro would integrate this scheduler ASAP or Linus would come to his senses and make the scheduler pluggable. I don't need fair behavior or 4096 CPU support on my netbook. I want it to react to my commands and play my media like it was supposed to be played, but I guess servers don't need that and so most of the kernel devs just don't give a shit.
Con Kolivas returns with a new scheduler Posted Sep 6, 2009 17:14 UTC (Sun) by jbh (subscriber, #494) [Link]
If your eeepc has an SSD, skips/freezes are more likely to come IO stalls
than from the CPU scheduler. Particularly if it's the 16GB variant of 900/900a, those are known to have very poor performance. In that case there are some mount options and other tunables that can make a large difference (disabling barriers and so on, let me know if you need a full list).
Or is this a conventional hard drive model?
Con Kolivas returns with a new scheduler Posted Sep 6, 2009 21:43 UTC (Sun) by kragil (guest, #34373) [Link]
Thank you.
It is a 901 with a fast 4GB SSD drive and a slow 8GB SSD. I have done some tweaking (Firefox ramdisk, ext4, noatime,noload) but maybe you have the right answers for my problems (I am using KDE4 on Fedora 11)
I will try 2.6.31 as soon as it is ready. I guess it might also help.
Con Kolivas returns with a new scheduler Posted Sep 7, 2009 8:56 UTC (Mon) by jbh (subscriber, #494) [Link]
Right! You probably have most things covered. Make sure you use the fast
ssd for the system of course, and save the 8GB for data. Three more things: - barrier=0 mount option - elevator=deadline boot option - tune2fs -o journal_data_writeback
The first one (mount -o barrier=0) is subjectively the one that makes the
I have a slow-only 16GB 900. With your setup, it might be effective to put
Finally it's possible to replace that slow SSD with a faster one from
Con Kolivas returns with a new scheduler Posted Sep 8, 2009 20:11 UTC (Tue) by realnc (guest, #60393) [Link]
You don't need an SSD. You need BFS. Cheaper and works wonders.
Con Kolivas returns with a new scheduler Posted Sep 9, 2009 7:43 UTC (Wed) by jbh (subscriber, #494) [Link]
Huh? I'm not sure what you mean, I already have an SSD. That's the problem: it's very slow, random writes <100kB/s. And I strongly doubt that BFS can magically fix that.
What CAN fix it is a combination of: (i) write less, (ii) don't wait for writes. That's the point of the tuning. Nothing to do with process scheduling.
Con Kolivas returns with a new scheduler Posted Sep 9, 2009 8:41 UTC (Wed) by realnc (guest, #60393) [Link]
This was related to the original comment by kragil you replied to. An SSD won't fix the problems described in this thread.
Con Kolivas returns with a new scheduler Posted Sep 9, 2009 8:47 UTC (Wed) by jbh (subscriber, #494) [Link]
Ah, then we're in full agreement. An SSD will in fact *cause* the problems
described in this thread.
;-)
Con Kolivas returns with a new scheduler Posted Sep 11, 2009 14:54 UTC (Fri) by SEMW (guest, #52697) [Link]
> - barrier=0 mount option
> - elevator=deadline boot option >- tune2fs -o journal_data_writeback
Regarding the Deadline i/o scheduler, according to Wikipedia, "The kernel docs suggest this is the preferred scheduler for database systems, especially if you have TCQ aware disks, or any system with high disk performance.". Since an ssd on an eeepc is neither a database system, nor TCQ aware (TCQ being meaningless for SSDs), nor has high disk performance, what property makes it good for that workload?
Con Kolivas returns with a new scheduler Posted Sep 11, 2009 15:45 UTC (Fri) by jbh (subscriber, #494) [Link]
Good question! The desired property here is mainly "not CFQ", since the
default CFQ scheduler seems to behave badly (wrt IO latency) with cheap SSDs. See for example http://forum.eeeuser.com/viewtopic.php?id=23580 .
The noop scheduler is also sometimes recommended, but the linked thread
[ it also recommends the following, which I haven't tried:
|
|
||||||||||||