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

[Dimitri John Ledkov]

On 11 October 2014 04:30, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov 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? 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.
>
> I think we've established earlier in the thread that there are reasons why
> it's appropriate for Kubuntu wanting to use CFQ (baloo uses features only
> available with that scheduler).  What's you're alternative implementation
> approach then?
>

Given that essentially lowest priority is requested under CFQ,
equivalent result should be possible to achieve with cgroups
containment.
Specifically by limiting CPU (cpu.shares set to 100 ~= 1/10 of the
default 1024) and/or IO weight (blkio.weight) and bandwidth
(blkio.throttle.read_bps_device / blkio.throttle.write_iops_device) of
the baloo process. This would then be a scheduler-independent solution
and make baloo a truly capped resources background process.

-- 
Regards,

Dimitri.