Nick Piggin recently announced on the lkml that he, Jens Axboe and Andrew Morton [interview] all are in agreement that the anticipatory scheduler [story] is stable enough for inclusion into Linus' mainline 2.5 development tree. He noted that there are some design issues with the elevator API itself and process I/O statistics, however acknowledging that it's not the right time for a redesign of these interfaces. The scheduler, they say, is ready for some mainline exposure.
Looking forward, Nick described Jens' current efforts to make the choice of schedulers be configurable at kernel compilation time at least, possibly evolving into a configurable that could be chosen/switched at runtime. Nick's announcement, in hopes of getting the anticipatory scheduler running as the default elevator in the 2.5 tree, included a number of comparison benchmarks with the current deadline scheduler. As we saw earlier [story], the anticipatory scheduler offers some significant performance boosts, such as noticably minimizing latency. Read on to see the actual results.
Update: (3/27/3) Added is a new email from Nick that also benchmarks the CFQ I/O scheduler [story]. He notes that the CFQ scheduler is still untuned, so don't read too much into the results.
From: Nick Piggin
Subject: [BENCHMARK] AS vs. DL schedulers
Date: Tue, 25 Mar 2003 17:35:44 +1100
Hi all,
Jens Axboe, Andrew Morton and I think that the IO scheduler we have been
working on is probably about ready to go into mainline. There are some
design issues with the elevator API and process IO statistics which are not
ideal, but we have agreed that now is not the time to redesign
interfaces.
Jens is looking into making the schedulers CONFIGurable and possibly
runtime selectable which should please everyone, though the present lack
of these features doesn't stop AS getting into 2.5 for testing. I would
hope AS gets a couple of revisions as the default elevator.
Here are some benchmarks.
Cat kernel source during seq read
DL - 0.03user 0.13system 5:21.39elapsed
AS - 0.02user 0.14system 0:14.50elapsed
Cat kernel source during seq write
DL - 0.03user 0.14system 14:06.45elapsed
AS - 0.02user 0.14system 0:16.33elapsed
ls -lr kernel source during seq read
DL - 0.18user 0.31system 0:24.32elapsed
AS - 0.19user 0.32system 0:09.39elapsed
ls -lr kernel source during seq write
DL - 0.23user 0.34system 1:13.90elapsed
AS - 0.18user 0.32system 0:05.49elapsed
Contest
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 69 95.7 0.0 0.0 1.00
2.5.65-mm4-as 1 69 95.7 0.0 0.0 1.00
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 149 46.3 121.0 22.8 2.16
2.5.65-mm4-as 1 100 70.0 81.2 22.0 1.45
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 91 78.0 12.8 6.6 1.32
2.5.65-mm4-as 1 100 72.0 15.6 8.0 1.45
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 87 78.2 5.0 18.4 1.26
2.5.65-mm4-as 1 94 72.3 6.0 19.1 1.36
tiobench
* note numbers at 256 threads are less dependant on the IO
scheduler due to the small number of request slots available
as default. Jens is looking into dynamically allocating requests.
Unit information
================
File size = 1024MB
Blk Size = 4096B
Sequential Reads
Num Avg Maximum Lat% Lat% CPU
Identifier Thr Rate (CPU%) Latency Latency >2s >10s Eff
--------------- --- ------ ------ --------- ----------- ----- ------ -----
2.5.65-mm4-dl 1 48.21 11.09% 0.080 36.49 0.00 0.00 435
2.5.65-mm4-dl 4 11.47 2.500% 1.358 86.84 0.00 0.00 459
2.5.65-mm4-dl 16 13.18 3.049% 4.704 311.43 0.00 0.00 432
2.5.65-mm4-dl 256 10.32 2.489% 58.877 69755.23 0.09 0.07 414
2.5.65-mm4-as 1 49.23 11.52% 0.078 28.10 0.00 0.00 427
2.5.65-mm4-as 4 39.56 9.461% 0.387 217.46 0.00 0.00 418
2.5.65-mm4-as 16 37.81 8.902% 1.571 929.76 0.00 0.00 425
2.5.65-mm4-as 256 33.10 7.822% 17.405 26072.15 0.25 0.05 423
Random Reads
2.5.65-mm4-dl 1 0.59 0.488% 6.647 23.35 0.00 0.00 120
2.5.65-mm4-dl 4 0.59 0.178% 26.003 96.85 0.00 0.00 332
2.5.65-mm4-dl 16 0.67 0.327% 88.082 403.66 0.00 0.00 206
2.5.65-mm4-dl 256 0.61 0.480% 1064.411 16058.51 3.02 2.68 127
2.5.65-mm4-as 1 0.57 0.504% 6.829 28.33 0.00 0.00 113
2.5.65-mm4-as 4 0.63 0.584% 23.283 220.36 0.00 0.00 108
2.5.65-mm4-as 16 0.63 0.624% 87.513 596.26 0.00 0.00 101
2.5.65-mm4-as 256 0.85 0.852% 659.708 14613.03 13.15 1.04 99
Sequential Writes
2.5.65-mm4-dl 1 42.85 20.66% 0.082 992.45 0.00 0.00 207
2.5.65-mm4-dl 4 43.04 20.94% 0.291 1104.10 0.00 0.00 205
2.5.65-mm4-dl 16 37.10 17.68% 1.188 6594.20 0.02 0.00 210
2.5.65-mm4-dl 256 29.38 14.76% 15.689 30675.42 0.17 0.06 199
2.5.65-mm4-as 1 44.15 21.43% 0.080 1025.37 0.00 0.00 206
2.5.65-mm4-as 4 40.94 19.79% 0.299 1087.51 0.00 0.00 207
2.5.65-mm4-as 16 35.62 16.89% 1.220 5965.63 0.02 0.00 211
2.5.65-mm4-as 256 28.20 14.15% 16.388 33732.92 0.17 0.06 199
Random Writes
2.5.65-mm4-dl 1 0.81 0.467% 0.033 32.69 0.00 0.00 174
2.5.65-mm4-dl 4 0.79 0.509% 0.934 75.36 0.00 0.00 155
2.5.65-mm4-dl 16 0.81 0.484% 3.573 518.44 0.00 0.00 166
2.5.65-mm4-dl 256 0.99 0.561% 48.837 7073.10 0.60 0.00 176
2.5.65-mm4-as 1 0.82 0.472% 0.034 32.15 0.00 0.00 174
2.5.65-mm4-as 4 0.81 0.518% 0.818 137.50 0.00 0.00 156
2.5.65-mm4-as 16 0.79 0.516% 4.735 476.85 0.00 0.00 153
2.5.65-mm4-as 256 0.94 0.524% 79.319 7416.65 0.96 0.00 179
OraSim
DL - 132, 144
AS - 129, 140
nickbench (IO rate is total combined throughput)
Bench 2 - 2 threads, streaming reader and streaming writer
DL - IO Rate: 33.36 MB/s, Reads per write: 0.08
AS - IO Rate: 42.19 MB/s, Reads per write: 2.08
Bench 3 - 2 threads, streaming readers
DL - IO Rate: 12.64 MB/s, Reads per read: 0.95
AS - IO Rate: 45.56 MB/s, Reads per read: 1.00
Bench 4 - 2 threads, streaming writers
DL - IO Rate: 38.59 MB/s, Writes per write: 1.45
AS - IO Rate: 40.64 MB/s, Writes per write: 1.68
Bench 5 - 2 thread, read then write each block of 1 file
DL - IO Rate: 40.24 MB/s, CPU time per byte: 4732.421875 us/B
AS - IO Rate: 45.30 MB/s, CPU time per byte: 5238.281250 us/B
Bench 6 - 4 threads, streaming readers
DL - IO Rate: 11.87 MB/s, Greatest unfairness between 4 readers: 0.95
AS - IO Rate: 44.89 MB/s, Greatest unfairness between 4 readers: 0.95
From: Nick Piggin
Subject: Re: [BENCHMARK] AS vs. DL schedulers
Date: Tue, 25 Mar 2003 17:56:56 +1100
On Tue, Mar 25, 2003 at 05:35:44PM +1100, Nick Piggin wrote:
>
> Here are some benchmarks.
>
Machine is UP PIV 2.0 (512K), 256MB no swap
ICH4: IDE controller at PCI slot 00:1f.1
hda: Maxtor 6E040L0, ATA DISK drive
Target fs for tests was ext2
The kernel used was actually 2.5.65-mm4 with a few minor tweaks to
as-iosched.cFrom: Nick Piggin
Subject: [BENCHMARKS] AS vs DL vs CFQ
Date: Thu, 27 Mar 2003 15:21:34 +1100
Due to popular demand I have done a CFQ run of these benchmarks on the
same kernel+hardware. DL and AS results are the results I previously
posted.
Summary: Looks like CFQ still has some problems which need sorting out,
AFAIK no tuning has been done, and Jens is currently caught up with
other important stuff. So, don't read too much into these results. They
are most useful as a bug report. Search for '*' to for my comments where
I have seen problems.
Cat kernel source during seq read
DL - 0.03user 0.13system 5:21.39elapsed
AS - 0.02user 0.14system 0:14.50elapsed
CF - 0.01user 0.13system 4:52.79elapsed
Cat kernel source during seq write
DL - 0.03user 0.14system 14:06.45elapsed
AS - 0.02user 0.14system 0:16.33elapsed
CF - N/A
* Test DNF after 20 minutes. "Equilibrium" state is
5s pauses between reads of ~500K and continual ~45MB/s writes
ls -lr kernel source during seq read
DL - 0.18user 0.31system 0:24.32elapsed
AS - 0.19user 0.32system 0:09.39elapsed
CF - 0.18user 0.29system 0:23.76elapsed
ls -lr kernel source during seq write
DL - 0.23user 0.34system 1:13.90elapsed
AS - 0.18user 0.32system 0:05.49elapsed
CF - 0.20user 0.33system 0:47.19elapsed
Contest
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 69 95.7 0.0 0.0 1.00
2.5.65-mm4-as 1 69 95.7 0.0 0.0 1.00
2.5.65-mm4-cf 1 69 95.7 0.0 0.0 1.00
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 149 46.3 121.0 22.8 2.16
2.5.65-mm4-as 1 100 70.0 81.2 22.0 1.45
2.5.65-mm4-cf 1 121 57.9 77.8 18.0 1.75
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 91 78.0 12.8 6.6 1.32
2.5.65-mm4-as 1 100 72.0 15.6 8.0 1.45
2.5.65-mm4-cf 1 92 76.1 12.5 6.5 1.33
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.65-mm4-dl 1 87 78.2 5.0 18.4 1.26
2.5.65-mm4-as 1 94 72.3 6.0 19.1 1.36
2.5.65-mm4-cf 1 89 76.4 5.0 18.0 1.29
tiobench
Only did 1 and 4 threads for CFQ. It is not a scheduler for a server.
Unit information
================
File size = 1024MB
Blk Size = 4096B
Sequential Reads
Num Avg Maximum Lat% Lat% CPU
Identifier Thr Rate (CPU%) Latency Latency >2s >10s Eff
--------------- --- ------ ------ --------- ----------- ----- ------ -----
2.5.65-mm4-dl 1 48.21 11.09% 0.080 36.49 0.00 0.00 435
2.5.65-mm4-dl 4 11.47 2.500% 1.358 86.84 0.00 0.00 459
2.5.65-mm4-dl 16 13.18 3.049% 4.704 311.43 0.00 0.00 432
2.5.65-mm4-dl 256 10.32 2.489% 58.877 69755.23 0.09 0.07 414
2.5.65-mm4-as 1 49.23 11.52% 0.078 28.10 0.00 0.00 427
2.5.65-mm4-as 4 39.56 9.461% 0.387 217.46 0.00 0.00 418
2.5.65-mm4-as 16 37.81 8.902% 1.571 929.76 0.00 0.00 425
2.5.65-mm4-as 256 33.10 7.822% 17.405 26072.15 0.25 0.05 423
2.5.65-mm4-cf 1 48.80 12.66% 0.079 28.16 0.00 0.00 385
2.5.65-mm4-cf 4 12.38 2.607% 1.184 276.88 0.00 0.00 475
Random Reads
2.5.65-mm4-dl 1 0.59 0.488% 6.647 23.35 0.00 0.00 120
2.5.65-mm4-dl 4 0.59 0.178% 26.003 96.85 0.00 0.00 332
2.5.65-mm4-dl 16 0.67 0.327% 88.082 403.66 0.00 0.00 206
2.5.65-mm4-dl 256 0.61 0.480% 1064.411 16058.51 3.02 2.68 127
2.5.65-mm4-as 1 0.57 0.504% 6.829 28.33 0.00 0.00 113
2.5.65-mm4-as 4 0.63 0.584% 23.283 220.36 0.00 0.00 108
2.5.65-mm4-as 16 0.63 0.624% 87.513 596.26 0.00 0.00 101
2.5.65-mm4-as 256 0.85 0.852% 659.708 14613.03 13.15 1.04 99
2.5.65-mm4-cf 1 0.59 0.554% 6.581 22.38 0.00 0.00 107
2.5.65-mm4-cf 4 0.59 0.203% 25.473 105.73 0.00 0.00 289
Sequential Writes
2.5.65-mm4-dl 1 42.85 20.66% 0.082 992.45 0.00 0.00 207
2.5.65-mm4-dl 4 43.04 20.94% 0.291 1104.10 0.00 0.00 205
2.5.65-mm4-dl 16 37.10 17.68% 1.188 6594.20 0.02 0.00 210
2.5.65-mm4-dl 256 29.38 14.76% 15.689 30675.42 0.17 0.06 199
2.5.65-mm4-as 1 44.15 21.43% 0.080 1025.37 0.00 0.00 206
2.5.65-mm4-as 4 40.94 19.79% 0.299 1087.51 0.00 0.00 207
2.5.65-mm4-as 16 35.62 16.89% 1.220 5965.63 0.02 0.00 211
2.5.65-mm4-as 256 28.20 14.15% 16.388 33732.92 0.17 0.06 199
2.5.65-mm4-cf 1 45.22 21.20% 0.078 1222.02 0.00 0.00 213
2.5.65-mm4-cf 4 33.45 15.87% 0.367 1602.89 0.00 0.00 211
Random Writes
2.5.65-mm4-dl 1 0.81 0.467% 0.033 32.69 0.00 0.00 174
2.5.65-mm4-dl 4 0.79 0.509% 0.934 75.36 0.00 0.00 155
2.5.65-mm4-dl 16 0.81 0.484% 3.573 518.44 0.00 0.00 166
2.5.65-mm4-dl 256 0.99 0.561% 48.837 7073.10 0.60 0.00 176
2.5.65-mm4-as 1 0.82 0.472% 0.034 32.15 0.00 0.00 174
2.5.65-mm4-as 4 0.81 0.518% 0.818 137.50 0.00 0.00 156
2.5.65-mm4-as 16 0.79 0.516% 4.735 476.85 0.00 0.00 153
2.5.65-mm4-as 256 0.94 0.524% 79.319 7416.65 0.96 0.00 179
2.5.65-mm4-cf 1 0.78 0.433% 0.334 25.19 0.00 0.00 180
2.5.65-mm4-cf 4 0.89 0.515% 4.068 12795.50 0.03 0.03 172
* CFQ has latency problems here for some reason.
OraSim (bigger is better)
DL - 132, 144
AS - 129, 140
CF - 97, 121
nickbench (IO rate is total combined throughput)
Bench 2 - 2 threads, streaming reader and streaming writer
DL - IO Rate: 33.36 MB/s, Reads per write: 0.08
AS - IO Rate: 42.19 MB/s, Reads per write: 2.08
CF - IO Rate: 32.00 MB/s, Reads per write: 0.12
Bench 3 - 2 threads, streaming readers
DL - IO Rate: 12.64 MB/s, Reads per read: 0.95
AS - IO Rate: 45.56 MB/s, Reads per read: 1.00
CF - IO Rate: 11.93 MB/s, Reads per read: 0.99
Bench 4 - 2 threads, streaming writers
DL - IO Rate: 38.59 MB/s, Writes per write: 1.45
AS - IO Rate: 40.64 MB/s, Writes per write: 1.68
CF - IO Rate: 37.88 MB/s, Writes per write: 1.66
Bench 5 - 1 thread, read then write each block of 1 file
DL - IO Rate: 40.24 MB/s, CPU time per byte: 4732.421875 us/B
AS - IO Rate: 45.30 MB/s, CPU time per byte: 5238.281250 us/B
CF - IO Rate: 38.80 MB/s, CPU time per byte: 4718.750000 us/B
Bench 6 - 4 threads, streaming readers
DL - IO Rate: 11.87 MB/s, Greatest unfairness between 4 readers: 0.95
AS - IO Rate: 44.89 MB/s, Greatest unfairness between 4 readers: 0.95
CF - IO Rate: 11.27 MB/s, Greatest unfairness between 4 readers: 0.5
* in this CFQ result, 2 threads read 256MB, 2 read 128MB
Clarification
Just a clarification - the issues I alluded to in my post aren't particularly bad.
The process IO tracking stuff is mainly a code cleanliness thing.
The elevator API issue is means we can lose accuracy in tracking process "thinktime" with TCQ enabled disks, and are unable to do automatic tuning for devices with different seek times (eg CDROM vs HDD). Nothing has been lost though.
It was done this way to minimise its impact on the rest of the system. 2.7 would be the right time for changing interfaces, backporting important improvements to 2.6.
As for running as the default elevator for 2.6 - its obviously out of my hands, however it would be nice if it could get a few of releases worth of exposure during 2.5, thus giving it much lrger testing coverage. Should it prove to be not to Linus' likeing, deadline could be made the default again.
One last thing - CFQ results not included because I didn't get time. I'll post updated results with CFQ sometime. Maybe over the next couple of days.
Re: # Thr's
One thing that I noticed is that it does consistently worse in the 4,16 # Thr's cases, but in others at least as good if not much better, esp. in the important cases.
Any reason why?
Which cases?
I assume you must be talking about max latency? If thats the case then you'll see the latencies aren't exactly very high to start with. But AS makes good use of its settings to get good performance - note throughput. Should you need lower latency you would lower read_expire.
Re: Which cases?
Whoops.. yeah, I was referring to the max latency. Was just thinking it'd make a better sell if you could say "improves in all cases."
Difficult
This is quite difficult. I mean the reason it gets such good throughput is because it gives each task a longer run at IO. I mean with 16 tasks, whats that? The longest a task wated was
Difficult
This is quite difficult. I mean the reason it gets such good throughput is because it gives each task a longer run at IO. I mean with 16 tasks, whats that? The longest a task wated was <1s. As desktop users won't be running this sort of load, its a shame to penalise ftp server (for example) throughput in case some desktop user ever tries...
_But_ I'll be trying to improve this with some dynamic adjustments etc for 2.7. Good stuff should be able to be backported.
What happens to the seq read
I've been following this for ages now and I haven't seen any info on what happens to the sequential read process that's going on in the background. How much does it suffer? Does the overall throughput drop due to all these little anticipatory pauses? Or is this a win-win situation?
During which test?
During the "cat kernel tree" test, the seq read rate for DL was around 20MB/s, for AS it was higher, 30 or so IIRC.
I LUV AS!
God I do hope this is included in 2.5 mainline - 2.6 will be one kicking release. I installed Andrew's mm4 release and the performance pickup even on a desktop was quite noticable - apps launch faster individually (though not tremendously so) and launching several apps at once is no longer a painful experience. Waaay smoother and over all very noticably faster. I'm sure for server uses it also rocks. Wow - I honestly do not see how I ever could stand 2.4 or earlier - with the new scheduler in 2.5.65, far improved threading performance, new VM, and now AS - wow, I'm dumbfounded. What a polish job - we've come a long way since 2.0 - which is the series I used when I first started Linux back around '98. Spiffy keen!
With ever increasing kernel sizes tho, will 2.6 once its stable run decently on an older box? I'm buying an old Sun Sparcstation 10 with 4 CPUs at 50 mhz a piece, probably similar in many ways to a 486 job. Its probably too low end to comfortably run Solaris 9 but I'm thinking Linux may just work out nicely.
It's not just AS in -mm
Your comment about individual application loading times is probably not so much due to AS (unless you're streaming reads and writes like crazy) but rather due to the nonlinear mmap code. See this URL for its announcement in -mm.
Although this is quite cool, and really improves application loading times, it makes life harder for the page replacement algorithms, and Andrew says that this kind of policy should be in userspace, namely in glibc. So don't expect to see that feature in the mainline kernel.
On another note, I've been running Linux on (uniprocessor) sparc32 hardware, and although it'll be nifty to see 2.6 working there, I'd expect that it'll be a long while before 2.6 matures on that platform.
Sparc64 will get there a lot faster. After all, it hasn't been all that long since even 2.4 worked properly on sparc32.
loading the whole app
I remember when it was considered a feature that Linux didn't do this like Windows. Demand paging lowers the memory pressure for applications -- especially big bloated ones like we see today where many pages will never be read at all :)
Are there any heuristics so that this doesn't happen if we are low on memory or if the system doesn't have much memory to begin with? Theoretically, if an application was 16MB and there was only 8MB of RAM in the system, would the application be unable to launch?
"was" being the operative word
I mean assuming stability, the end result really just boils down to speed.
Anyway, the unused pages should be paged out easily (not sure if this currently happens) so not cause trouble for the VM. It saves having to take faults. The more IO issued at once the better the IO scheduler can perform.
I guess it is not appropriate under high memory pressure - not sure what the story is with that though.
2.5.x still has issues with old machines
hi,
have an old pentium box, and although the kernel compiles/installs flawlessly, the system simply reboots even before the ACPI step is reached.
I did read somewhere once that a bug was found which was "earlier" causing problems while booting an old system, but i thought it was corrected then! This problem, has disallowed me to let my pentium box be up2date...
robins
Report the bug
Get the latest 2.4 kernel and capture dmesg, lspci, cpuinfo, etc from it. Report that to the list and someone should help you from there.
Feature freeze
Nick,
Not to piss anyone off or anything, but how exactly does this change fit in the picture of a feature freeze? For example, are there any interactions with the IDE system which really needs some work still. It would be a shame to see everybody hop on to newest features without getting the other new features and significant changes (improvements) debugged first.
Scheduler change in feature freeze
The current feature freeze is not a hard line one, and I think its been mentioend before this might be able to fall under teh category of bug fix sicne bad performance is a bug.
From the way things sound, it seems liek a fairly self contained change
From my point of view
Its OK. I know everyone would like to see their "thing" merged, but it really doesn't change any core code (well it does a _tiny_ bit in quite a trivial way). It hasn't caused any problems since a few mms ago. The whole thing has been made to fit into the existing elevator API, so if the IDE system abides by the rules it should still work.
Considering we'll probably see things like like objrmap _maybe_ even shared pagetables, page clustering going in then I think this is the least of everyone's worries.
That said it really doesn't bother me one way or the other if it gets in or if nobody uses it. I'll be using it - I don't drink coffee so I'd rather wait 15 _seconds_ to grep the kernel source :P
In my opinion it should get i
In my opinion it should get in. It's a nice feature,
but i don't consider it a "core" feature. Anyway, you can still
make deadline the default.
And if it doesn't get in, everybody knows it'll be used as
a patchset anyway....a lot of people _need_ AS.
(BTW, i don't have a thing clear. The original AS papers mention freebsd. But freebsd already does this? or they don't like it for some reason?)
FreeBSD has multiple scheduler selection
It's at kernel compile time now but could be at runtime.
cvs
CPU schedulers
is what I think this page is referring to.
But...
the article is about IO schedulers.
Which scheduler for desktop use?
The way I understand this, AS shines primarily on servers, where it maximises throughput, whereas CFQ-scheduler is better for desktops since it minimizes latency (altrought it was mentined that AS also improves latency). Is that correct? AS for servers, CFQ for desktops?
I use AS on my desktop
with fab success. The latency isn't all that bad, hell its better then 2.4 most of the time and the throughput increases are very noticable. I have a habit of launching several apps at once after I log in and AS shortens the launch time of several apps very noticably. I recoomend it, but hey - I'm not a multimedia person - though I will say I *never* experience XMMS sound skips so far on any recent 2.5 kernels, especially 2.5.65 and up.
~Christopher
lol
Kinda funny comment if you think about it :)
Poor CFQ results
I understand that CFQ hasn't had much tuning, but what this untuned version has done is it has had a remarkable placebo effect on users. In the 4 thread tiobench it is consistently outdone by AS or DL or both in terms of maximum latency, in no test does it achieve remarkable throughput, and it has fairness problems and plain not working properly problems. Yet most people who have tried it assure everyone that it is the best thing since sliced bread for desktop use :P
Maybe AS should be renamed to something more fancy in order to get more people on the bandwagon! Almost Completely Fair Non-Queued Anticipatory Scheduler? ACFNQAS is almost certianly the best scheduler ever devised for every workload!!! Include it in 2.6! :P
In benchmark number 6 how did
In benchmark number 6 how did you measure the unfairness between the 4 readers?