[SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty

[Harald Sitter]

On Sat, Oct 11, 2014 at 12:51 AM, Dimitri John Ledkov <xnox at ubuntu.com> wrote:
> On 10 October 2014 11:26, Jonathan Riddell <jr at jriddell.org> wrote:
>> On Thu, Oct 09, 2014 at 09:02:04AM -0700, Steve Langasek wrote:
>>> On Thu, Oct 09, 2014 at 05:39:33PM +0200, Rohan Garg wrote:
>>> > > So while I still don't agree that this is free of risk of regression (e.g.,
>>> > > a system with both kubuntu and ubuntu desktops installed could see a direct
>>> > > regression under the ubuntu session as a result of this change), I also
>>> >
>>> > Could you elaborate a bit on how this would affect the unity session? Sure
>>> > performance might take a hit in certain cases, and we're very well
>>> > aware of that,
>>>
>>> As I said, the switch to deadline was seen to address existing problems with
>>> applications on the unity desktop (when running on an HDD) becoming
>>> non-responsive under heavy I/O.  Switching back to cfq is likely to
>>> reintroduce this problem.
>>
>> Is there any further information on this?  The upstream Baloo author
>> would like to know why his work is causing unnecessary slowdowns for
>> Kubuntu users and getting his work bad name.
>>
>> This is a change that has been done from upstream Linux and Ubuntu is
>> the only distro to make such a change so I find it very hard to
>> believe that going back to upstream default would cause a problem.
>> These changes are in utopic where it solves the problem of slugging
>> Kubuntu systems very nicely.  So I'd ask the SRU team to consider
>> letting this is again without delay.
>>
>
>
> Ubuntu is far from the only distribution that uses deadline by
> default. I am no longer using rotational media, as all my computers
> running SSDs, thus cannot test it today. I can brush the dust of my
> rotational drives and test this out. But back in the day I used to
> switch to deadline scheduler to improve responsiveness of my systems.
> I do not agree with the approach taken here (adjusting via udev rule),
> as that's unexpected from a settings-only package which should be
> DE-specific and shouldn't affect things outside of that scope.
> Specifically, deadline scheduler by default gives priority to read
> operations. Deadline schedule has proven to beat CFQ in database and
> virtual machine host workloads. Can you please explain how Baloo
> works?

Sets ioniceness. Reads all the things as fast as IO permits.

> Does it block on write operations, and/or it writes more than
> it reads?

It doesn't block, or rather it doesn't care, everything else cares due
to how deadline works, also see
http://irclogs.ubuntu.com/2014/10/08/%23ubuntu-kernel.html#t12:56

> Reading the bug report, the only concern is "extreme desktop
> sluggishness". I can see that deadline scheduler may make initial
> desktop login longer, given that indexer kicks in and fills up the
> queues.

Deadline processes deadlined requests with highest priority reading
things in a manner that is not sorted by sector as soon as things
start to deadline which in turn will make more things deadline as
unordered access on rationale is not very 'nice', also see the irc
log.

> So far it seems we have a conflict of interest here, given
> that all parties involved claim "my desktop sluggish" with one or the
> other scheduler - can we please devise a non-subjective numeric
> benchmarks that we can use here? Time from call boot to auto-login &
> auto-launch default web-browser and load up start.ubuntu.com without
> any caches for any indexes and e.g. 10GB of user data? Deadline
> scheduler has proven benchmarks and beats CFQ scheduler on many
> work-loads including the important database & virtual machine host
> (qemu-kvm block io access).

Not so important on a desktop system.

> Given that we have upstart available in
> both user and system session, can we delay launching baloo instead of
> starting it straight away, such that it doesn't affect read-heavy
> initial login?

Wouldn't do anything as it has nothing to do with login but load
balancing with deadline (primarily the lack of ioniceness support).

> My preference is to revert this change in utopic, as it's not
> appropriate for a DE settings package to change scheduler and penalize
> known workloads that perform best under deadline scheduler.

We can't release Kubuntu then.

HS