Can't Change IO Scheduler

[farukdgn]

I have been experiencing performance issues while copying big files and I have found out that the CFQ scheduler was responsible for this. So I decided to switch to deadline scheduler using "echo deadline > /sys/block/sda/queue/scheduler" and it was better.

Now I want to make this change permanent, so I followed instructions I found in forums and added "elevator=deadline" to "GRUB_CMDLINE_LINUX_DEFAULT" command in /etc/default/grub. But when I restart, "cat /sys/block/sda/queue/scheduler" still says that CFQ is used.

What am I doing wrong?

[acheron]

Did you run sudo update-grub before rebooting?

Depending on whether you have a SSD or rotational HD, I guess

/etc/udev/rules.d/60-ssd-scheduler.rules

could also be overriding your choice.

[farukdgn]

Did you run sudo update-grub before rebooting?

Depending on whether you have a SSD or rotational HD, I guess

/etc/udev/rules.d/60-ssd-scheduler.rules

could also be overriding your choice.

Yes I have run sudo update-grub.

I have HDD (SSHD actually). What file should I edit and how? I have two files in rules.d folder: 60-ssd-scheduler.rules and 70-snap.core.rules

[oshunluvr]

What are the contents of 60-ssd-scheduler.rules?

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

[farukdgn]

It was

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",ATTR{queue/scheduler}="cfq"

before. I changed it. Thank you!

[oshunluvr]

Odd that that's the default, since "cfq" is the default scheduler. Also, the rotational=1 bit means that rule doesn't apply to SSDs anyway.

Seems the devs may have overlooked this one...

[Snowhog]

Odd that that's the default, since "cfq" is the default scheduler. Also, the rotational=1 bit means that rule doesn't apply to SSDs anyway.

Seems the devs may have overlooked this one...

The OP states that he has an SSHD:

SSHD stand for solid-state hybrid drive. It's a traditional hard disk with a small amount of solid-state storage built in, typically 8GB or so. The drive appears as a single device to Windows (or any other operating system), and a controller chip decides which data is stored on the SSD and what's left on the HDD.

[acheron]

Odd that that's the default, since "cfq" is the default scheduler. Also, the rotational=1 bit means that rule doesn't apply to SSDs anyway.

Seems the devs may have overlooked this one...

Not overlooked, as this was was the default in kubuntu-settings from some years - mitigating issues with the i/o behaviour of nepomuk and baloo.

Our default for non rotational HD now happens to coincide with the new kernel defaults in 17.04

Arguable that it can now be removed from default settings, but as this came to light fairly late in 17.04 I think was decided was best NOT to mess with it at the last minute.

[oshunluvr]

Not overlooked, as this was was the default in kubuntu-settings from some years - mitigating issues with the i/o behaviour of nepomuk and baloo.

Our default for non rotational HD now happens to coincide with the new kernel defaults in 17.04

Arguable that it can now be removed from default settings, but as this came to light fairly late in 17.04 I think was decided was best NOT to mess with it at the last minute.

Ok, so not overlooked but ignored, understandable because it really has no effect. The point I wanted to make is why make the default scheduler cfq AND have a udev rule to set the rotational devices as cfq - seems redundant since all devices are cfq by default. That's why it seemed like it was overlooked, but I get it now. I believe the kernel team does testing of various schedulers and that's why it changes from time-to-time. And of course, there's never a single solution that satisfies everyone. Thus - udev rules.

Also seemingly illogical, on the surface at least, is a udev rule titled "60-ssd-scheduler.rules" with no rules that actually apply to ssd's. I guess calling it "60-not-ssd-scheduler.rules" would have been silly but just "60-scheduler.rules" like other distros would have worked. Just nit-picking now I suppose.

Actually, it seems now with the commonality of mixed drive types a more diverse default udev rule for this might be a good idea. Question: If one edits the default rule, would it be subject to a possible change by an update down the road? Not a version change, but a kernel change or package update. If so, would it be better to write a complete rule and use a different name so it wouldn't be over-written or made obsolete down the road? Lots of changes possible to an LTS install.

[oshunluvr]

The OP states that he has an SSHD:

Yeah, I would assume a hybrid would be "rotational" but if you think about it, might benefit from the scheduler change because of the ssd caching. I would be interested to know what differences there are.

[oshunluvr]

...and to throw one more variable into the mix, we'll may have BFQ - Budget Fair Queueing - by kernel 4.12. Supposedly improvements is throughput and latency.

[acheron]

https://launchpad.net/ubuntu/+source...1:17.10ubuntu1

[oshunluvr]

https://launchpad.net/ubuntu/+source...1:17.10ubuntu1

Awesome. Now @here:

[FONT=monospace][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ cat /etc/udev/rules.d/61-scheduler.rules[/COLOR]
# set deadline scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

[/FONT]

I love udev rules. IMO, one of the greatest improvements to come down in a long time.

[wizard10000]

Really interesting benchmarks with 4.9 kernel here -

http://openbenchmarking.org/result/1...SC61&obr_sor=y

discuss?

[oshunluvr]

There doesn't seem to be huge differences in most case, just sometimes. Also, one wins in one place while another wins elsewhere. Illustrates that this is no simple issue. It would be interesting to do a full spectrum of file systems, drive types, and kernel versions.