You are not logged in.

#1 2011-07-27 23:07:15

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Kernel IO schedulers: noop works better... why?

I've noticed that the CFQ scheduler sometimes doesn't seem to work very well, e.g. responsiveness visibly suffers when there's a lot of disk I/O going on. Deadline seems to be a little better under those conditions, but not much.

I'd avoided using the noop scheduler, of course, because it would make the disk do more work... Right?

But today I saw this: https://bugs.launchpad.net/ubuntu/+sour … bug/381300 And lo and behold, when I tried the noop scheduler on my netbook, it made things much more responsive under load.

Suffice to say I'm kind of stumped. I can't think of any good reason why a scheduler that does nothing to minimize disk labor should perform better... The only thing that occurs to me is that maybe SATA drives' native command queuing somehow messes with the scheduling, and I'm not altogether sure that idea makes sense.

Is this just some strange quirk of my netbook's hardware, or is there a good reason for noop to work better on desktops?

Edit: Hmm, I'm noticing lower CPU use by tasks that use a lot of disk I/O. Maybe that has something to do with it?

Last edited by Gullible Jones (2011-07-27 23:12:44)

Offline

#2 2011-07-28 15:39:11

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

Interesting...

typically, i have always thought that noop was best for SSD, though?

Myself, i have never been all that impressed by CFQ or even CFS (cpu scheduler). Whenever, i am running a stock kernel, i experience simliar io related slowdowns, and the CFS cpu scheduler generally, seems to not work that well for desktop usage (including multimedia stuff).

Instead of using CFQ ~ i use BFQ ... and BFS over CFS ... (Kernel26-ck).

Once i am running -ck ... my desktop is fast, not to heavy of cpu usage on I/O and the like.

but the question still remains why is noop working better?  maybe it is hardware related, you said you are using SATA... noop definitely doesn't work better on my SATA 6G drive than BFQ (and i would assume CFQ as well) but obviously my setup is much different than a netbook

(4:501)$ uname -a
Linux ninez 2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 14:57:41 CEST 2011 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
5943/8004MB    0.00 0.04 0.10 1/231 12774
[12756:12750 0:502] 11:37:54 Thu Jul 28 [ninez@ninez: +4] ~ 
(4:502)$ 

i hope someone has a better answer for you ~ i am interested myself wink

Last edited by triplesquarednine (2011-07-28 15:40:33)

Offline

#3 2011-07-28 18:01:58

unikum
Member
From: Russia
Registered: 2010-09-04
Posts: 151
Website

Re: Kernel IO schedulers: noop works better... why?

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

Offline

#4 2011-07-28 18:21:24

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

interesting, i will test this out to see for myself.

thanx

Offline

#5 2011-07-28 18:51:02

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: Kernel IO schedulers: noop works better... why?

triplesquarednine wrote:
unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

interesting, i will test this out to see for myself.

thanx

I'd appreciate if you let us know the results when you're done with the test.

I'm using noop for the SSD, and i wanted to know which one is best (between CFQ, BFQ and noop) for HDDs when AHCI is enabled.

Last edited by Viper_Scull (2011-07-28 18:51:43)


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#6 2011-07-28 19:13:35

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

Do you have any hard data to support this statement?


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#7 2011-07-28 19:37:11

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

Viper_Scull wrote:
triplesquarednine wrote:
unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

interesting, i will test this out to see for myself.

thanx

I'd appreciate if you let us know the results when you're done with the test.

I'm using noop for the SSD, and i wanted to know which one is best (between CFQ, BFQ and noop) for HDDs when AHCI is enabled.

well, for SSD i have heard time and time again noop is best, as for SATA 6G - i am very doubtful this will be the case.

but yes, i can probably do that (post results) - when i am sitting in front of my mani desktop at home (not at home right now). I'll also have to figure out / research the benchmarking tools i will likely want to use too. ~ the last time i did something like this was testing BFQ well over a year ago, so i don't really remember the details.

cheerz

Offline

#8 2011-07-28 19:41:00

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

graysky wrote:
unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

Do you have any hard data to support this statement?

lol.  Graysky ~ that is why i wrote below his statement;

interesting, i will test this out to see for myself.

I don't think noop will outperform BFQ on my hardware.

sidenote: (as i assume you might have some good tips!)

what tools should i be using to benchmark noop vs. BFQ ???  (this could save me a lot of reading, if you got some info)

thanks

Offline

#9 2011-07-28 19:42:33

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: Kernel IO schedulers: noop works better... why?

@triplesquarednine, be sure to include deadline when you plan to test on an SSD.


ᶘ ᵒᴥᵒᶅ

Offline

#10 2011-07-28 19:55:58

einhard
Member
From: Poland
Registered: 2010-01-05
Posts: 89

Re: Kernel IO schedulers: noop works better... why?

unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

I can't confirm this. On my old laptop I have Seagate Momentus 7200.2 (ST9200420AS) which supports NCQ. With enabled AHCI I don't see much difference beetwen cfq and noop, but bfq is noticeably more responsive, especially on heavy load.

In my case, responsiveness and overall performance look like this
bfq >> cfq >= noop

With noop I have 5s slower boot (to KDE), compared to bfq, and 2-3s slower compared to cfq. There aren't any significant differences with:

hdparm -t --direct /dev/sda

CPU load is slightly lower with noop on heavy IO work. My disk is also 96% full so it may have some effect on schedulers.

The good question is, how to measure responsiveness and compare bfq, cfq, noop.

Last edited by einhard (2011-07-28 20:07:02)

Offline

#11 2011-07-28 20:02:21

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

litemotiv wrote:

@triplesquarednine, be sure to include deadline when you plan to test on an SSD.

Litmotiv, I think you may have read what i said wrong, i am testing against SATA 6G ~ i had said that i have read that noop is good for SSD. I do plan on buying an SSD for this machine soon, but not quite yet wink

cheerz

Offline

#12 2011-07-29 03:08:03

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: Kernel IO schedulers: noop works better... why?

einhard: boot does seem a couple seconds slower with noop than with deadline, but I'm not doing any scientific measurements, just counting seconds (inaccurately).

Where I really notice the difference is when multitasking. With deadline and especially cfq, Firefox likes to hiccup whenever hard drive I/O happens. With noop, there's much less hiccuping.

Offline

#13 2011-07-29 08:35:41

brebs
Member
Registered: 2007-04-03
Posts: 3,465

Re: Kernel IO schedulers: noop works better... why?

Gullible Jones wrote:

responsiveness visibly suffers when there's a lot of disk I/O going on

commit=60 will probably help. I wonder whether noop doesn't enforce the default commit=5 as much as CFQ?

Also, use the ionice command on your batch I/O processes. With BFS, I have a handy alias set up:

alias verynice='ionice -c3 schedtool -D -e'

Last edited by brebs (2011-07-29 08:36:58)

Offline

#14 2011-07-29 08:41:16

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

Here's a benchmark I propose - like to get some feedback before I write the script and do it:

A script generates a bunch files of varying sizes using dd from /dev/random: two groups: 1K to 100 K as group A and then 1 M to 100 M as group B.  So now we have say a total of say, 5 GB of group A files and 5 GB of group B files.  Now, use the time command to measure how many sec it takes to copy these files from partition X to partition Y.  Clean up the 10 GB of files on each partition so that disc cache isn't a factor before repeat the process 5 times totally logging the data each time to give some statistical power.  Do this for each IO scheduler then compare results.  Again, this would be done an a physical HDD with AHCI enabled and one that has NCQ, not on an SSD.

Thoughts?


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#15 2011-07-29 09:27:02

einhard
Member
From: Poland
Registered: 2010-01-05
Posts: 89

Re: Kernel IO schedulers: noop works better... why?

graysky wrote:

Here's a benchmark I propose - like to get some feedback before I write the script and do it:

A script generates a bunch files of varying sizes using dd from /dev/random: two groups: 1K to 100 K as group A and then 1 M to 100 M as group B.  So now we have say a total of say, 5 GB of group A files and 5 GB of group B files.  Now, use the time command to measure how many sec it takes to copy these files from partition X to partition Y.  Clean up the 10 GB of files on each partition so that disc cache isn't a factor before repeat the process 5 times totally logging the data each time to give some statistical power.  Do this for each IO scheduler then compare results.  Again, this would be done an a physical HDD with AHCI enabled and one that has NCQ, not on an SSD.

Thoughts?

I don't think it will give any significant differences. Like I have mentioned before hdparm -t --direct /dev/sda was almost the same on every scheduler. The most important part here is simultaneous access/reading data, not nicely arranged tasks: writing->copying->deleting. This will be good for testing different filesystems, NCQ and AHCI but probably not efficiency of schedulers. I think some parallel IO work must be done in the same time but It will be hard to write something that is repeatable. Maybe measuring with time command script which creates in the same time several sets of data (parallel commands with &) and other that copies many sets at the same time to other directory or partition will be better choice. This won't measure responsiveness but at least performance on heavy IO load.

Why copying from partition X to Y? It shouldn't matter to scheduler.

Offline

#16 2011-07-29 17:22:39

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

Good point... but at the same time, I wouldn't want to design something that doesn't mimic typical desktop workloads.  After all, how many of us copy tons of files in parallel?  I just don't know what a good test would be to contrast the three...


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#17 2011-07-29 17:33:25

LeCrayonVert
Member
Registered: 2010-09-01
Posts: 133

Re: Kernel IO schedulers: noop works better... why?

You could use phoronix-test-suite to do some benchmarks. Here are the available disk related tests :

phoronix-test-suite list-available-tests | grep Disk

pts/aio-stress               - AIO-Stress                          Disk     
pts/blogbench                - BlogBench                           Disk     
pts/compilebench             - Compile Bench                       Disk     
pts/dbench                   - Dbench                              Disk     
pts/fio                      - Flexible IO Tester                  Disk     
pts/fs-mark                  - FS-Mark                             Disk     
pts/hdparm-read              - hdparm Timed Disk Reads             Disk     
pts/iozone                   - IOzone                              Disk     
pts/postmark                 - PostMark                            Disk     
pts/sqlite                   - SQLite                              Disk     
pts/tiobench                 - Threaded I/O Tester                 Disk     
pts/unpack-linux             - Unpacking The Linux Kernel          Disk     

I believe in a world I can and do understand. A rational universe, explained through rational means.

Offline

#18 2011-07-29 17:40:37

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

@LCV - sure but which one is the most relevant to this question?


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#19 2011-07-29 17:46:09

Gusar
Member
Registered: 2009-08-25
Posts: 3,500

Re: Kernel IO schedulers: noop works better... why?

graysky wrote:

@LCV - sure but which one is the most relevant to this question?

None, I would say. What we're interested in is how responsive a system is during heavy i/o. It's hard to benchmark that, mainly because it's very subjective.

Offline

#20 2011-07-29 18:20:08

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

hey guys,

i think iozone might be the best tool to use. it does a slew of testing, including things like latency ~ which is useful to have, being as latency actually affects interactiveness/responsiveness. multi-process measurement, etc. and we can throw some other numbers into the mix (such as me using jackd at the same time (automated)...lol + using my desktop)  i'm having issues getting the scripts that generate the gnuplot / 3d graphs to work, and i don't have time today to look at it. but it's probably as good or better than what Phoronix is offering, and i have a feeling it is more in depth and relevent for this type of test. ~ it's also cross-platform and runs on a ton of platforms. the package in AUR is about a year old, so you might want to grab sources from their website;

http://www.iozone.org/

i did build from AUR, but then ended up installing the newest version, you'll also require gnuplot to be installed.

i think you will have to modify '/usr/bin/gnu3d.dem' in order to get the 3dplot to work, that is where i was stuck (not really, i just have other things i need to get done right now wink )

i can tell you right now though, noop didn't go through the test the fastest and on bigger reads and writes seemed slower / took longer. including nautilus taking forever to display my home folder contents :\

I will have another stab at this and try to get some data generated (aside from the 4 files i have now; bfq-io.txt , noop-io.txt, cfg-io.txt, deadline-io.txt). i'll post when i have it.

~cheerz

Last edited by triplesquarednine (2011-07-29 18:52:45)

Offline

#21 2011-07-29 18:31:27

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: Kernel IO schedulers: noop works better... why?

Gusar wrote:
graysky wrote:

@LCV - sure but which one is the most relevant to this question?

None, I would say. What we're interested in is how responsive a system is during heavy i/o. It's hard to benchmark that, mainly because it's very subjective.

Jackd + heavy i/o (maybe iozone) + interacting with the DE might be a good testing candidate wink

based on the number xruns, interactivity with the desktop, how applications run, etc. ~ that's how i used to tune/optimize non-rt kernels to perform like RT, when my hardware on a particular machine wasn't supported very well (by RT). - i am still able to have zero xruns, and use that crappy laptop (which now lives in a rackmount, and runs 2.6.37-zen) as a musical instrument (actually, several -> synths/samplers/sooperlooper).

i'll probably do a test like that over here, but this new machine has only been running a few days, and i haven't even touched the proaudio side of things yet, hell i haven't even installed VMware, or any of my VMs (for work) yet. lazy man! lol.

EDIT: and while i totally agree it is subjective for this type of benchmark, what isn't that subjective is how many xruns i would be getting vs. how well each scheduler benchmarked (in iozone) ... as that is number crunching. the only part of the mix that is subjective is observation, but enough repeated tests, even through observation (including, the numbers) will yield a winner (on my machine anyway).

cheerz

Last edited by triplesquarednine (2011-07-29 18:42:03)

Offline

#22 2011-07-30 07:08:45

unikum
Member
From: Russia
Registered: 2010-09-04
Posts: 151
Website

Re: Kernel IO schedulers: noop works better... why?

graysky wrote:
unikum wrote:

If hard drives support NCQ and in the motherboard BIOS enabled AHCI mode noop work better than other shedulers.

Do you have any hard data to support this statement?

During high I/O usage my system responsiveness beter (subjectively).

--
Related links:
https://hep.pa.msu.edu/twiki/bin/view/A … rnelTuning
http://doom10.org/index.php?topic=78.0

Last edited by unikum (2011-07-30 07:28:57)

Offline

#23 2011-07-30 07:54:19

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

@unikum - interesting links... the msu.edu one is the most relevant one, but he used a RAID... interesting none the less, thanks!

Last edited by graysky (2011-07-30 07:55:20)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#24 2011-07-30 09:48:16

unikum
Member
From: Russia
Registered: 2010-09-04
Posts: 151
Website

Re: Kernel IO schedulers: noop works better... why?

We need a standart benchmark. May be somebody will write script with hdparm, time, cp or tar, like this:

DISC="sda"; \
 cat /sys/block/$DISC/queue/scheduler; \
 for T in noop deadline cfq; do \
     echo $T > /sys/block/$DISC/queue/scheduler; \
     cat /sys/block/$DISC/queue/scheduler; \
     sync && /sbin/hdparm -tT /dev/$DISC && echo "----"; \
     sleep 15; \
 done

This will allow us to compare the results.

Last edited by unikum (2011-07-30 09:50:05)

Offline

#25 2011-07-30 10:02:49

graysky
Member
From: The worse toilet in Scotland
Registered: 2008-12-01
Posts: 8,814
Website

Re: Kernel IO schedulers: noop works better... why?

@unikum - yeah, but need to use iozone not hdparm...

EDIT:  I started a new thread so as not to contaminate this one with technical aspects of iozone.  Feel free to join the discussion, see results of the three schedulers, etc.

Last edited by graysky (2011-07-30 11:00:55)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

Board footer

Powered by FluxBB