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

[Scott Kitterman]

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?

Scott K