Slashdot Mirror
Anticipatory Scheduler in Kernel 2.5+ Benchmarked
gmuslera points to this article at KernelTrap comparing available benchmarks for schedulers available for the 2.5 kernel, with the 2.4's scheduler as a reference poin. "In some cases, the new Anticipatory Scheduler performs several times better than the others, doing a task in a few seconds instead minutes like the others."
I have a multithreaded perl app (yes perl has descent thread support in 5.6 and later) which does a lot of mixed write/read I/O to and from a database. With 2.4 and 40 threads I can hardly use the system (of course I dont have to abuse my computer with 80 threads but Im trying to prove a point here).
Switching to a new tabbed terminal in fluxbox it takes ages to redraw and switching between virtual desktops is an act of futility.
With 2.5 It get good interactive performance and don't see this effect much at all. For sure this is also a bit due to the new VM code.
Of course I would probably get the best interactivity with the SFQ scheduler but thats secondary in this case. At least xmms doesn't skip with this during very heavy I/O. I do not use the new NPTL code which would help further I suppose.
Mozilla's Bugzilla does this now.
... redirect all /. requests to a Google-cache of your webpage (assuming you're lucky enough to have the page cached before someone notices).
Perhaps one better
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
What does it do for kernel performance? Or does it do anything for performance? ...I haven't run Linux on a desktop for almost a year. It hurts mommy.. please make the bad man go away!
- Jimbob
I know that's Score:5 Funny but there's a serious note here.
If a site is down, Mozilla could pretty easily grab the google cache instead. Or, if there's no google cache or if the cache matches the current page, check archive.org. Mozilla could auto-generate a page offering the user some options. Think about it - it would be the end of 404 errors. Instead of
404 The requested page could not be found.
you could get
The site you requested is currently down. Would you like to use Google's cache instead? I also have a snapshot of the page you requested from August 12, 2002 but older ones are available here.
High-speed Road Trip (18.000KPH)
I remember Ingo Molnar introducing this scheduler running in O(1) time months ago, sometimes late in 2002... AFAIK it is a part of the 2.5 kernel for quite a long time.. and at the time it was first tested there were some benchmarks.. I vaguely remember something about "we tried to launch several hundreds of processes, w.o. the scheduler: 15 minutes, w. the scheduler: 2 seconds." So what is so new about some benchmarks being available?
Or am I completely off-topic? ;)
I second that (albeit only 2 months). I used to have many problems compiling 2.5, but the newer releases are truly wonderful, also the new module system kick ass, esp. now when I can compile ALSA in and not worry about a thing. 2.5 is WAY easier to get up and running than 2.4, I really recommend trying it out, but be sure to read Documentation/Changes ! (although I run Debian/Woody and didn't bother to upgrade anything except module-init-tools, works for me ;)
Oh, and while ur at it u might want to take a look at devfs too (I run it without devfsd and I didn't have any problems, u just need to change inittab from ttyX to vc/X, fstab and lilo/grub).
The only kinks I had was with xine which doesn't like v4l, but mplayer works fine... Hmm, oh and same FPS for Q3, I doubt that any of u will feel much difference anywhere (unless u didn't use the preempt patch for 2.4). But I haven't played with NPTL yet, does anybody have any experience with that?
what goes up must come down, ask any sysop / sig11
Although I _suspect_ they will run fine on 2.5, I don't want to risk it. It's still a little too bleeding edge for me. They call it bleeding edge for a reason, because you _will_ bleed and get hurt from time to time.
I guess I am a big fat ninny when it comes to bleeding edge stuff (although I do lust for all the new toys, the waiting just increases my contentness when such cool stuff gets part of stable stuff) :-)
Speaking of avoiding the bleeding edge, it would be sooo cool if this IO scheduler was backported to 2.4.
I'm currently enrolled in cs 162 (OSs) at UC Berkeley, todays lecture was on different flavors of schedulers and this scheduler was mentioned breifly. For more theoretical info see http://webcast.berkeley.edu/courses/archive.html?p rog=116&group=52 for a webcast of the lecture or http://inst.eecs.berkeley.edu/~cs162/Lectures/L11. pdf for a pdf of the lecutre notes.
At the same time I'm not quite sure where a solution like adaptive I/O scheduling would help on a real system because, in our example of an Apache server, whilst it is stalled writing a web page to you over TCP, it can be reading another page off disk for me. In a true server load, there is little think time because the next request comes in.
The article mentions multiple simultaneous writes and reads... Doing two tasks at once in much more expensive than doing them sequentially.
.5 second to get a login screen.
Why not use the download manager programs... for all file transfering?
My priorities:
1. user interface responds effectively in realtime.
2. CD writes don't fail
3. Video doesn't skip
4. files transfer quickly.
I would actually like the ability to switch the mode of the file schedualer.
If I am not doing 2. or 3. then why not switch to something that makes 4 happen?
I saw something rediculous, like a 10 second wait for a login prompt??!?!
The system should have that all ready ahead of time, and it should take no more than
--I don't care about spelling enough to spend the vast quantity of time to get this to the spell checker.
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
X11 tru, but not even what makes timing so different. it is windows taking care of its gui (or at least much of it) in process with the OS that really changes things. x11 has to go through system calls.
Nah, it handles certain start-up costs for complex applications better. This may or may not have anything to do with multithreading per se.
I don't run KDE, but I understand that it has had speed issues in the past because it uses a lot of interconnected C++ shared libraries, which really tax the dynamic loader. The Windows link scheme, by the way, is much more primitive (read: fast at runtime). Microsoft also uses a hack (disk layout profiling) to speed up load time further. (Not that "hack" is necessarily a bad thing - after all it does get the job done.)
A couple of years ago, Jakub Jelinek came up with a utility similar to IRIX Quickstart for ELF binaries / libraries, which does "prelinking" to dramatically reduce relocation overhead at runtime in the common cases (without sacrificing flexibility, for the uncommon cases). A side effect is reducing memory usage due to COW. I never heard what happened to that project - anyone know if it is considered production-quality yet, or if binutils / glibc will be shipping it any time soon? Apparently it helped KDE quite a bit.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README