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

[Dimitri John Ledkov]

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? Does it block on write operations, and/or it writes more than
it reads? 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. 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). 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?

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.

-- 
Regards,

Dimitri.