Bug 66

We should aim to be able to set the default io scheduler for devices like this even if the zaurus is still no longer in tree

This seems reasonable and I'll start looking into it. As I lack the history here, why the comment about "even if the zaurus is ... no longer in tree"?

I see that on the beagleboard (which is known to boot from a microSD card) we only have the noop scheduler available:

# cat /sys/block/md0/queue/scheduler                          
none

When the image we prepare can be written to any number of devices (spinning disk, usb key, DOM, SSD, etc) it could be that one scheduler performs better than another depending on the media. Flash media doesn't suffer from seek latencies, but there appears to be concern that reads can be starved with the noop scheduler and that the deadline scheduler is a better choice. From what I can gather, workload will also impact which IO scheduler will perform best.

As such, I'm not inclined to try and make a minor performance enhancement which seems to be just as likely to backfire under certain workloads. I believe the right thing to do is to enable noop,CFQ, and deadline as part of the base linux-yocto branch and allow users to customize their own images with the "elevator=noop|cfq|deadline" kernel cmdline.

Bruce, any thoughts on that?

I'd like to hear back from Bruce and possibly Ross if he's still interested before taking any action.

At least the for the 2.6.37 kernel, this is already the situation. Looking
at my qemux86 and beagleboard 2.6.37 based kernels, I have:

CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

In the .configs, so all of the options should be available. 

A quick check on my atom-pc-stable build also shows the same settings,
which is what I'd expect.

The thinking is the same as the conclusion that Darren came to, this is
a BSP (or more precisely a deployment specific) option, so choosing any
one option in particular is a matter left up to the final customization of
the BSP. 

Even if we automatically detected the image type, there still remains
the possibility that the BSP developer would want to override a setting, which
would mean a series of detected defaults, with a place for final override, etc. 

So the design decision is to keep them all available and either let the default
be chosen by Kconfig in the BSP, or on the bootline.

No response from the original submitter or others. I suggest we close as will not fix as Bruce and I are in agreement here. We can open another bug should something similar come up in the future for which our responses here are not adequate.

I think old imported bugs somehow don't email the original reporters any more. 

There is a general configuration issue still standing here - how would I specify in a machine configuration file that for my root and home partitions I would like the NOOP scheduler?

I actually thought that this was mostly solved now, the kernel exposes a "rotational" property on block devices.  I assumed that this was used to change the default scheduler, but maybe you don't ever want noop because it doesn't do *anything* like collapsing identical reads. Who knows, certainly not me!

Anyway, the point was that the "rotational" block property should be useful for this, if this is something you actually want to do.

Whilst it might expose a rotatable parameter does anything act upon that? Certainly userspace doesn't, not sure about the kernel schedulers internally. Identical reads should hit the disk cache fwiw.

In the machine config, specify the following to set your preferred elevator:

APPEND += "elevator=(cfq|deadline|noop)"

No activity in over a year. Assuming the provided mechanism is adequate. Closing.