On Monday, October 13, 2014 11:54:54 PM Dimitri John Ledkov wrote: > On 11 October 2014 04:30, Scott Kitterman <ubu...@kitterman.com> wrote: > > On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov wrote: > >> On 10 October 2014 11:26, Jonathan Riddell <j...@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.
Are you offering to implement this? Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
