Hi,

1) no it was always in (almost) complete idle

2) a bigger value even made it worse, setting it to "0" however
seemingly "fixed" it, I however don't know how the overall
effect/impact is, this will need some more real-world testing ;)

cat /sys/block/sdd/queue/iosched/slice_idle
0

hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  314 MB in  3.01 seconds = 104.32 MB/sec

hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  312 MB in  3.00 seconds = 103.86 MB/sec

hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  314 MB in  3.01 seconds = 104.24 MB/sec

one side-node / question:

will this cause more wakeups on the cpu and/or decrease battery

oops, didn't know that, thanks - didn't want to give the wrong person
the "credits"
hi & kudos to Jens ;)

here's a nice site which explains all of the settings:

http://www.nextre.it/oracledocs/ioscheduler_03.html

Regards

Mat
--

As Fabio said, you may lose throughput if you have multiple processes
with at least one sync. seq. reader.  However, for other workloads, you
should see a large global throughput improvement.  This is because CFQ
tends to idle without too much regard to thinktime or seekiness, often
wasting a few ms.  The trade-off is that your slow sync. processes may
suffer a little.

 -- Aaron
--

Well, it's not a fix... the overall effect is that you should end
up with more seeks (and so reduced throughput) on loads consisting
of more than one process, and at least one of those processes is a

I don't know the overall effect on battery life, btw with no idling
you have one less timer active in the system (that however, depending
on the load, does not fire frequently) and more continuous disk
activity.
--