Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Tue, Oct 14, 2014 at 07:25:16AM +0200, Harald Sitter wrote: > On Tue, Oct 14, 2014 at 2:07 AM, Scott Kitterman wrote: > >> 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? > Implementation aside, I am not sure this would be a suitable > replacement (someone should check with upstream ;)). From what I > gather the notion is that baloo should index as fast as possible given > resources are available. Throttling through a cgroup containment would > lower the available resources in general, wouldn't it? This is > supposedly why ioniceness was used instead. If nothing is going on the > indexer can work at full speed, while if the user is actually doing > something baloo essentially allows the kernel to IO starve it to allow > the rest of the system to be snappy. - blkio.weight - Specifies per cgroup weight. This is default weight of the group on all the devices until and unless overridden by per device rule. (See blkio.weight_device). Currently allowed range of weights is from 10 to 1000. https://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt However, this file also says: Currently two IO control policies are implemented. First one is proportional weight time based division of disk policy. It is implemented in CFQ. So in fact, ths seems to suffer from the same limitation as ionice. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [ubuntu-release] Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Tue, Oct 21, 2014 at 12:44:34AM -0400, Steve Langasek wrote: > We've agreed that the kubuntu-settings > change is acceptable for an SRU in spite of reservations; Great, please approve it into trusty-proposed Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Steve Langasek [2014-10-21 0:44 -0400]: > But without that, something like the proposed cgroup handling is > probably in order. FYI, something similar is currently being discussed for Tracker, which has pretty much the same problem: http://lists.freedesktop.org/archives/systemd-devel/2014-October/023952.html Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Thu, Oct 16, 2014 at 04:23:36PM +0200, Rohan Garg wrote: > > A consistent kernel and performance expectations across Ubuntu is also > > worthwhile. I don't want someone screw up database/VM/etc. workloads > > benchmarks simply > > because they happen to have kubuntu-desktop installed or left around > Are we honestly optimizing for benchmarks now? I'd rather optimize for > a good user experience, which in the case of Kubuntu requires the use > of CFQ. I couldn't care less about > random-news-site-running-random-benchmarks. I don't think Dimitri actually meant "benchmarks" here. I think "workload performance" is the real question. There seems to be a grave misunderstanding that the scheduler change was working around a bug in Unity (cf. https://blogs.kde.org/2014/10/15/ubuntus-linux-scheduler-or-why-baloo-might-be-slowing-your-system-1404). This was *never* about a bug in Unity; Unity simply has a feature that provides visual indication to the user when an application is unresponsive, and with CFQ on HDD, many users found their apps were unresponsive quite a lot. Removing the visual indicator wouldn't improve app responsiveness for these users; the configurations in question would still have been sluggish under CFQ. That baloo is not well-modeled by the performance testing that was done before, is clear. But changing the scheduler for the whole system is a very big hammer, not to be used lightly. We've agreed that the kubuntu-settings change is acceptable for an SRU in spite of reservations; but it's in everyone's interest - including that of Kubuntu users who run VMs on their desktop, or other workloads that suffer under CFQ - to find a long-term solution that doesn't require such a heavy-handed change. If someone were to demonstrate that CFQ is actually better than deadline with recent kernels across all relevant workloads, then it's a no-brainer to switch back. But without that, something like the proposed cgroup handling is probably in order. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Thu, Oct 16, 2014 at 04:23:36PM +0200, Rohan Garg wrote: > > A consistent kernel and performance expectations across Ubuntu is also > > worthwhile. I don't want someone screw up database/VM/etc. workloads > > benchmarks simply > > because they happen to have kubuntu-desktop installed or left around > > Are we honestly optimizing for benchmarks now? I'd rather optimize for > a good user experience, which in the case of Kubuntu requires the use > of CFQ. I couldn't care less about > random-news-site-running-random-benchmarks. For clarity this was not not changed recently, deadline has been the default scheduler for at least the last two LTS releases, 2.5+ years. It was changed to fix apparent user experience issues under high disks loads, such as greying out windows and unresponsive shells. The change was made after these user reports and only after positive testing there _and_ benchmarking results also showed advantage to a number of server workloads. A similar level of care should be applied before any additional change. -apw -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
> A consistent kernel and performance expectations across Ubuntu is also > worthwhile. I don't want someone screw up database/VM/etc. workloads > benchmarks simply > because they happen to have kubuntu-desktop installed or left around Are we honestly optimizing for benchmarks now? I'd rather optimize for a good user experience, which in the case of Kubuntu requires the use of CFQ. I couldn't care less about random-news-site-running-random-benchmarks. Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On 14 October 2014 12:24, Jonathan Riddell wrote: > On Mon, Oct 13, 2014 at 11:54:54PM +0100, Dimitri John Ledkov wrote: >> 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. > > Whyever should KDE software be rewritten to deal with Ubuntu altering > the upstream defaults of Linux? Fix Unity. > I'm merely proposing to set cgroups stanzas in the upstart system or session job that spawn that particular process. I haven't mentioned Unity in no point, but rather that deadline scheduler outperforms CFQ in variety of workloads, and thus there are users out there choosing there. Imho the default kernel config choice here is correct for the diverse workloads Ubuntu is subject to. A consistent kernel and performance expectations across Ubuntu is also worthwhile. I don't want someone screw up database/VM/etc. workloads benchmarks simply because they happen to have kubuntu-desktop installed or left around on their system. And such a high level component as baloo shouldn't make such low level assumptions about the kernel config, even if adjustable at runtime. If that's true, I demand kernel config to be optimised for Emacs elisp virtual machine since clearly nothing else should matter! -- Regards, Dimitri. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Mon, Oct 13, 2014 at 11:54:54PM +0100, Dimitri John Ledkov wrote: > 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. Whyever should KDE software be rewritten to deal with Ubuntu altering the upstream defaults of Linux? Fix Unity. Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Tue, Oct 14, 2014 at 2:07 AM, Scott Kitterman wrote: >> 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? Implementation aside, I am not sure this would be a suitable replacement (someone should check with upstream ;)). From what I gather the notion is that baloo should index as fast as possible given resources are available. Throttling through a cgroup containment would lower the available resources in general, wouldn't it? This is supposedly why ioniceness was used instead. If nothing is going on the indexer can work at full speed, while if the user is actually doing something baloo essentially allows the kernel to IO starve it to allow the rest of the system to be snappy. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Monday, October 13, 2014 11:54:54 PM Dimitri John Ledkov wrote: > On 11 October 2014 04:30, Scott Kitterman wrote: > > On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov wrote: > >> On 10 October 2014 11:26, Jonathan Riddell 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
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On 11 October 2014 04:30, Scott Kitterman wrote: > On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov wrote: >> On 10 October 2014 11:26, Jonathan Riddell 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 kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Friday, October 10, 2014 23:51:18 Dimitri John Ledkov wrote: > On 10 October 2014 11:26, Jonathan Riddell 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 -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Fri, Oct 10, 2014 at 11:26:20AM +0100, Jonathan Riddell 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: > 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. I am not willing to personally sign off on this SRU, because I don't think it provably passes the "no regressions" threshold. And I don't think that the SRU team as a whole should let this into -proposed without the kind of thorough regression test case that I outlined in my previous mail to ubuntu-release (which will minimize the regressions, but still doesn't prove that there aren't any). I also agree with what Scott wrote on the bug report. This is not a recent behavior change in the Ubuntu kernel; it is the sort of thing that we should take the time to gather as much data as possible about, before pushing this change out in an SRU. Gathering data on top of the 14.10 release is a useful way to do this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Sat, Oct 11, 2014 at 2:27 AM, Steve Langasek wrote: > On Thu, Oct 09, 2014 at 06:15:17PM +0200, Rohan Garg wrote: >> I'd rather work with data which we have right now ( general feedback from >> users suggests that baloo performance is quite bad with deadline and >> improves with the switch to CFQ ) rather than making assumptions based on >> outdated data. > > The previous bugs aren't invalidated by being dated, any more than Ubuntu > deltas from Debian should be summarily dropped on merge without examination. FWIW, I find it incredibly concerning that we actually go through the trouble of manually merging and evaluating the delta against Debian in random packages while a substantial core delta such as a different IO scheduler doesn't even have a well defined test case for why the delta is there let alone gets re-evaluated ever so often. Food for thought. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Sat, Oct 11, 2014 at 12:51 AM, Dimitri John Ledkov wrote: > On 10 October 2014 11:26, Jonathan Riddell 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? Sets ioniceness. Reads all the things as fast as IO permits. > Does it block on write operations, and/or it writes more than > it reads? It doesn't block, or rather it doesn't care, everything else cares due to how deadline works, also see http://irclogs.ubuntu.com/2014/10/08/%23ubuntu-kernel.html#t12:56 > 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. Deadline processes deadlined requests with highest priority reading things in a manner that is not sorted by sector as soon as things start to deadline which in turn will make more things deadline as unordered access on rationale is not very 'nice', also see the irc log. > 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). Not so important on a desktop system. > 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? Wouldn't do anything as it has nothing to do with login but load balancing with deadline (primarily the lack of ioniceness support). > 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. We can't release Kubuntu then. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Thu, Oct 09, 2014 at 06:15:17PM +0200, Rohan Garg wrote: > > 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. > Right and this data is fairly out of date right? I mean, is there up to > date data on whether or not switching to CFQ will definitely cause issues > in Unity? It's the most current data we have. There's no more current data because users aren't running Unity with cfq on HDDs today. It's fundamental to this class of problem that you can't test it without subjecting users to possible regressions. I'm not saying that this should block the SRU. But it *should* inform the kind of regression testing done as part of the SRU. In particular, someone (or multiple someones) will need to test this kubuntu package on a trusty system with a rotational disk as part of the SRU verification. I would ask that the SRU verifiers also test: - installing an Ubuntu precise desktop with unity7 (which I believe was the last release using cfq by default) and the .0 kernel (3.2.0) - using the system for a bit to try to reproduce the original problem - application windows becoming grayed out by the WM under normal usage, indicating that the app is not responding - changing the scheduler to deadline and testing to see if the problem persists or resolves itself - upgrading to the trusty backport kernel (linux-image-generic-lts-trusty) - verifying that the desktop behaves correctly with the default deadline scheduler - changing the scheduler to cfq and testing whether the original problem recurs > I'd rather work with data which we have right now ( general feedback from > users suggests that baloo performance is quite bad with deadline and > improves with the switch to CFQ ) rather than making assumptions based on > outdated data. The previous bugs aren't invalidated by being dated, any more than Ubuntu deltas from Debian should be summarily dropped on merge without examination. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On 10 October 2014 11:26, Jonathan Riddell 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. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
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. Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Thu, Oct 9, 2014 at 6:32 PM, Stephen Michael Kellat wrote: > On Thu, 9 Oct 2014 18:15:17 +0200 > Rohan Garg wrote: > > [snip] >> > >> > I thought that Edubuntu was still including both Ubuntu and Kubuntu >> > on their DVD, which would be a clear example of why this would be >> > the case. It doesn't look like Kubuntu is on that image anymore, >> > so maybe this is a negligible use case. >> > >> >> The udev rule is shipped via the kubuntu-settings package which does >> not land in the Edubuntu install manifest [1]. So I'm pretty sure >> this does not impact them at all. >> >> Cheers >> Rohan Garg >> >> [1] >> http://cdimages.ubuntu.com/xubuntu/releases/trusty/release/xubuntu-14.04-desktop-amd64.manifest > [snip] > > That would actually be our manifest out in Xubuntu country, I would suggest > consulting this instead for Edubuntu's manifest: > > http://cdimages.ubuntu.com/edubuntu/releases/14.04.1/release/edubuntu-14.04-dvd-amd64.manifest > Whoops, thanks for that :) Manifest still has no kubuntu-settings-* packages though. Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Hi > 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. > Right and this data is fairly out of date right? I mean, is there up to date data on whether or not switching to CFQ will definitely cause issues in Unity? I'd rather work with data which we have right now ( general feedback from users suggests that baloo performance is quite bad with deadline and improves with the switch to CFQ ) rather than making assumptions based on outdated data. >> but the pro's of changing the scheduler to cfq in order to get better >> performance in a KDE session >> outweigh this performance hit ( if there is one ). > > How do they outweigh it? I think you can only say they outweigh it if > you're running the Kubuntu desktop. If you're running the Ubuntu desktop, > but have the Kubuntu desktop installed, you will have a different > assessment. > > I thought that Edubuntu was still including both Ubuntu and Kubuntu on their > DVD, which would be a clear example of why this would be the case. It > doesn't look like Kubuntu is on that image anymore, so maybe this is a > negligible use case. > The udev rule is shipped via the kubuntu-settings package which does not land in the Edubuntu install manifest [1]. So I'm pretty sure this does not impact them at all. Cheers Rohan Garg [1] http://cdimages.ubuntu.com/xubuntu/releases/trusty/release/xubuntu-14.04-desktop-amd64.manifest -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
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. > but the pro's of changing the scheduler to cfq in order to get better > performance in a KDE session > outweigh this performance hit ( if there is one ). How do they outweigh it? I think you can only say they outweigh it if you're running the Kubuntu desktop. If you're running the Ubuntu desktop, but have the Kubuntu desktop installed, you will have a different assessment. I thought that Edubuntu was still including both Ubuntu and Kubuntu on their DVD, which would be a clear example of why this would be the case. It doesn't look like Kubuntu is on that image anymore, so maybe this is a negligible use case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
> 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, but the pro's of changing the scheduler to cfq in order to get better performance in a KDE session outweigh this performance hit ( if there is one ). And could be we move forward with the SRU itself? Anyone want to approve it from the -proposed queue? Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Thu, Oct 9, 2014 at 8:07 AM, Martin Pitt wrote: > Steve Langasek [2014-10-08 13:10 -0700]: >> It has been pointed out that Ubuntu also has an indexer, zeitgeist, which >> apparently doesn't suffer from the same problem. > > To clarify: For the most part, zeitgeist only stores access events, i. > e. metadata like "accessed this video at this time". There have been > some experiments with making it index full file contents, but I don't > believe we have/use that. > > In earlier Ubuntu releases we used to install various file content > indexers by default (like tracker), and in the end they all sucked. By > nature they are using ginormous I/O and nontrivial CPU bandwidth all > the time, causing both desktop slowdown and much higher battery drain. > > So the desktop team decided some time ago to not install a file > indexer by default. People who actually do want this can install > tracker. The desktop slowdown can probably be addressed with some > clever scheduler/ionice/whatever magic, but the cpu/IO/power usage > will not go down no matter how you schedule things. > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -- > Ubuntu-release mailing list > ubuntu-rele...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > Just as a side note, the udev rule that I introduced only changes the scheduler for rotational media. If the disk is a SSD, there is no change to the scheduler. Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Steve Langasek [2014-10-08 13:10 -0700]: > It has been pointed out that Ubuntu also has an indexer, zeitgeist, which > apparently doesn't suffer from the same problem. To clarify: For the most part, zeitgeist only stores access events, i. e. metadata like "accessed this video at this time". There have been some experiments with making it index full file contents, but I don't believe we have/use that. In earlier Ubuntu releases we used to install various file content indexers by default (like tracker), and in the end they all sucked. By nature they are using ginormous I/O and nontrivial CPU bandwidth all the time, causing both desktop slowdown and much higher battery drain. So the desktop team decided some time ago to not install a file indexer by default. People who actually do want this can install tracker. The desktop slowdown can probably be addressed with some clever scheduler/ionice/whatever magic, but the cpu/IO/power usage will not go down no matter how you schedule things. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On Wed, Oct 08, 2014 at 10:20:23AM -0700, Steve Langasek wrote: > On Wed, Oct 08, 2014 at 05:42:48PM +0100, Colin Ian King wrote: > > > Also, what exactly do you mean when you say baloo doesn't "implement > > > ionice > > > support"? The 'ionice' tool is part of the base system (util-linux). It > > > would be a simple matter of packaging to always run baloo under ionice. > > Linux supports I/O scheduling priorities since 2.6.13 just with the CFQ > > io scheduler. > Sorry, I don't understand. Do you mean that 'ionice' doesn't help when > using the deadline scheduler? Ok, I've caught up on the IRC discussion on this and have a better understanding now. To summarize: - baloo does use ionice, but ionice has no effect when the deadline scheduler is used. There is also no equivalent to ionice for deadline that would let baloo declare that it should be given lower priority. - benchmarks for deadline vs. cfq on rotational disks are mixed; and the change to use deadline was done in part *because of* applications being i/o-starved and unresponsive on the Ubuntu desktop, which was mitigated by this switch. - due to the lack of per-process userspace controls on the deadline scheduler, overriding the kernel scheduler seems to be the only way to give a reasonable experience for kubuntu on rotational disks 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 don't see any better way to fix it. So while I wouldn't be comfortable with a kubuntu-specific udev rule in an SRU, I also wouldn't try to block it. It has been pointed out that Ubuntu also has an indexer, zeitgeist, which apparently doesn't suffer from the same problem. Perhaps the KDE team would want to take a look to understand what zeitgeist is doing differently that makes it compatible with the deadline scheduler. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On 14-10-08 01:25 PM, Steve Riley wrote: > On 2014-10-08 09:36:03 Steve Langasek wrote: >> >> I don't think it's at all appropriate for a desktop environment to install a >> udev rule which changes the kernel scheduler. That's a severe layering >> violation, and it means that anyone who installs kubuntu-desktop on an >> existing system will significantly change the performance characteristics of >> that system. > > To my knowledge, Ubuntu is the only distribution that changes upstream's > default from CFQ to deadline. I read the Launchpad bugs and the linked IRC > logs; it seems that the reasons for making the change (around the time of > Precise) have been largely forgotten. Perhaps it's worth revisiting the > decision? > Actually, I believe RHEL 7 uses deadline by default on all devices except SATA disks. Marc. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
On 2014-10-08 09:36:03 Steve Langasek wrote: > > I don't think it's at all appropriate for a desktop environment to install a > udev rule which changes the kernel scheduler. That's a severe layering > violation, and it means that anyone who installs kubuntu-desktop on an > existing system will significantly change the performance characteristics of > that system. To my knowledge, Ubuntu is the only distribution that changes upstream's default from CFQ to deadline. I read the Launchpad bugs and the linked IRC logs; it seems that the reasons for making the change (around the time of Precise) have been largely forgotten. Perhaps it's worth revisiting the decision? > I also think it's categorically wrong to say that there's minimal chance of > regression. These schedulers have pretty fundamentally different > characteristics, and where CFQ behaves pathologically for one process (the > indexer), deadline will behave pathologically for others. How much testing did Ubuntu do before changing away from upstream's default? Which aspects of Ubuntu performed "pathologically" that necessitated the change? > I don't think it's at all acceptable to work around a kernel bug in a > kubuntu-settings SRU. The right fix is to resolve this in the kernel > package instead. (Bug #1310402) Cc:ing the kernel team. > > Also, what exactly do you mean when you say baloo doesn't "implement ionice > support"? The 'ionice' tool is part of the base system (util-linux). It > would be a simple matter of packaging to always run baloo under ionice. To clarify: Baloo _does_ use ionice. It's the lack of support for ionice in the deadline scheduler that's the root of the problem here. ...Steve Riley -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Hi Colin, On Wed, Oct 08, 2014 at 05:42:48PM +0100, Colin Ian King wrote: > > Also, what exactly do you mean when you say baloo doesn't "implement ionice > > support"? The 'ionice' tool is part of the base system (util-linux). It > > would be a simple matter of packaging to always run baloo under ionice. > Linux supports I/O scheduling priorities since 2.6.13 just with the CFQ > io scheduler. Sorry, I don't understand. Do you mean that 'ionice' doesn't help when using the deadline scheduler? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/10/14 17:36, Steve Langasek wrote: > Hi Jonathan, > > On Wed, Oct 08, 2014 at 03:56:42PM +0100, Jonathan Riddell wrote: >> Me and Rohan would like a second opinion on bug 1378789 >> [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty >> https://launchpad.net/bugs/1378789 > >> The kernel team have changed the scheduler away from upstream Linux >> defaults to deadlock which causes our desktop indexing programme Baloo >> to run very slow and take up lots of resources because it doesn't >> implement ionice suport. We'd like to update kubuntu-settings with a >> udev rule to change back to CFQ. > >> We've changed this in utopic. There's minimal chance of regressions, >> it's an upstream default recommended by Linux and Baloo. We're >> getting quite a few reports of people saying their system is sluggish >> and the baloo upstream author is most grumpy. > >> Scott would rather wait until after utopic is out where it would get >> more testing, but I doubt there will be much that most users can say >> beyond "it's not horribly slow". > > I don't think it's at all appropriate for a desktop environment to install a > udev rule which changes the kernel scheduler. That's a severe layering > violation, and it means that anyone who installs kubuntu-desktop on an > existing system will significantly change the performance characteristics of > that system. > > I also think it's categorically wrong to say that there's minimal chance of > regression. These schedulers have pretty fundamentally different > characteristics, and where CFQ behaves pathologically for one process (the > indexer), deadline will behave pathologically for others. > > I don't think it's at all acceptable to work around a kernel bug in a > kubuntu-settings SRU. The right fix is to resolve this in the kernel > package instead. (Bug #1310402) Cc:ing the kernel team. > > Also, what exactly do you mean when you say baloo doesn't "implement ionice > support"? The 'ionice' tool is part of the base system (util-linux). It > would be a simple matter of packaging to always run baloo under ionice. Linux supports I/O scheduling priorities since 2.6.13 just with the CFQ io scheduler. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUNWmHAAoJEGjCh9/GqAImE1oP/0cRps85qcUvLxtO84smMTzp HHw0HNu21Wot20wC4PgmI4+XHWpEifbjYMnLFU99DUGvSHeieZFy6nq0BN/30gKg FBP7aif0P9hCeTrTBCN1YG18PsY71dhc9QatWz3xjhQc/VFVU9I8F4k6i4Sk1sD2 zBRPeI5m4q66nmipAe1/+5FEJbxQJV7+3xYOp8QQPwpaJKHu29Zp6m/GPvxM10kS 1DhYy6RI/1LiC8L867cn6IN1eC30LaECKwPr8kI9/lfp4M0BdYiQOtyLDlchLdjS ZH8XaPiV2SMEsQCNlu4/8CPU2yoxKnVR8LZInJPVljctYvZqB2+EK97S9x6mAwXk 8DjHlvjy0O57V5T+5q0cbOfG6FQ8iExBNkO9waY27iRcneLvhQyEnz4boNKgSG2B JOv+DP64wiSHnKV0Q2pq7zBzlNFvaVj8wRYmGM9NTTjuCL1IocVt1j5HgGNWJawb FTKWVWqwzlANMhZLMcX8sfgVoZoD4t7fhe7fhLbkoCp0Bvto4EPmXRI/gOCRE19R qQAdrVVXd1X3oDMR7dZFEYEZ+JELJKgsg6RgQkFeRIoc0TbhY9EMxQhHG6kzQJvM WfeVAXsGo6e9IAAMCsVT0vc8jbuyS6ioz8meyyGRXvtdbF/wFAKf/Aacdo3upq6H PaeN3Z7C9Edseb50itoU =yBjp -END PGP SIGNATURE- -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Hi Jonathan, On Wed, Oct 08, 2014 at 03:56:42PM +0100, Jonathan Riddell wrote: > Me and Rohan would like a second opinion on bug 1378789 > [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty > https://launchpad.net/bugs/1378789 > The kernel team have changed the scheduler away from upstream Linux > defaults to deadlock which causes our desktop indexing programme Baloo > to run very slow and take up lots of resources because it doesn't > implement ionice suport. We'd like to update kubuntu-settings with a > udev rule to change back to CFQ. > We've changed this in utopic. There's minimal chance of regressions, > it's an upstream default recommended by Linux and Baloo. We're > getting quite a few reports of people saying their system is sluggish > and the baloo upstream author is most grumpy. > Scott would rather wait until after utopic is out where it would get > more testing, but I doubt there will be much that most users can say > beyond "it's not horribly slow". I don't think it's at all appropriate for a desktop environment to install a udev rule which changes the kernel scheduler. That's a severe layering violation, and it means that anyone who installs kubuntu-desktop on an existing system will significantly change the performance characteristics of that system. I also think it's categorically wrong to say that there's minimal chance of regression. These schedulers have pretty fundamentally different characteristics, and where CFQ behaves pathologically for one process (the indexer), deadline will behave pathologically for others. I don't think it's at all acceptable to work around a kernel bug in a kubuntu-settings SRU. The right fix is to resolve this in the kernel package instead. (Bug #1310402) Cc:ing the kernel team. Also, what exactly do you mean when you say baloo doesn't "implement ionice support"? The 'ionice' tool is part of the base system (util-linux). It would be a simple matter of packaging to always run baloo under ionice. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty
Cautious is what SRUs are about. If someone else on the SRU team feels differently, I don't mind being overridden. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
