On 11 October 2014 04:30, Scott Kitterman <[email protected]> wrote: > On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov wrote: >> On 10 October 2014 11:26, Jonathan Riddell <[email protected]> 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. -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
