| 2009-09-10 07:59:46 |
Sam Davies |
bug |
|
|
added bug |
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
BootDmesg.txt http://launchpadlibrarian.net/31580108/BootDmesg.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
CurrentDmesg.txt http://launchpadlibrarian.net/31580110/CurrentDmesg.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
Dependencies.txt http://launchpadlibrarian.net/31580112/Dependencies.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
HalComputerInfo.txt http://launchpadlibrarian.net/31580113/HalComputerInfo.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
Lspci.txt http://launchpadlibrarian.net/31580114/Lspci.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
Lsusb.txt http://launchpadlibrarian.net/31580115/Lsusb.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
ProcCpuinfo.txt http://launchpadlibrarian.net/31580116/ProcCpuinfo.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
ProcInterrupts.txt http://launchpadlibrarian.net/31580117/ProcInterrupts.txt |
|
| 2009-09-10 07:59:46 |
Sam Davies |
attachment added |
|
ProcModules.txt http://launchpadlibrarian.net/31580118/ProcModules.txt |
|
| 2009-09-10 08:01:43 |
Sam Davies |
description |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094).
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/sdx/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which could possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 .
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/sdx/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which could possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
|
| 2009-09-10 08:03:49 |
Sam Davies |
description |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 .
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/sdx/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which could possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 , especially since numerous users in that bug thread have reported significant improvements in responsiveness after changing i/o schedulers.
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/sdx/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which could possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
|
| 2009-09-10 08:44:07 |
Sam Davies |
description |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 , especially since numerous users in that bug thread have reported significant improvements in responsiveness after changing i/o schedulers.
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/sdx/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which could possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.
DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.
With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 , especially since numerous users in that bug thread have reported significant improvements in responsiveness after changing i/o schedulers.
To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:
sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M
where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.
The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/$PARTITION/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.
Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which might possibly be tuned more for server-type workloads) may not be the best option.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux |
|
| 2009-09-18 19:27:51 |
Leann Ogasawara |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2009-09-18 19:27:51 |
Leann Ogasawara |
linux (Ubuntu): status |
New |
Triaged |
|
| 2010-03-23 06:49:44 |
Jeremy Foshee |
tags |
amd64 apport-bug |
amd64 apport-bug kj-triage |
|
| 2010-03-23 06:49:46 |
Jeremy Foshee |
linux (Ubuntu): status |
Triaged |
Incomplete |
|
| 2010-04-09 11:47:25 |
Andreas Raster |
removed subscriber Andreas Raster |
|
|
|
| 2010-04-29 23:00:40 |
Petter |
removed subscriber Petter |
|
|
|
| 2010-06-14 19:48:34 |
Jeremy Foshee |
tags |
amd64 apport-bug kj-triage |
amd64 apport-bug kj-expired kj-triage |
|
| 2010-06-14 19:48:40 |
Jeremy Foshee |
linux (Ubuntu): status |
Incomplete |
Expired |
|
| 2010-06-14 21:32:22 |
jhfhlkjlj |
linux (Ubuntu): status |
Expired |
Confirmed |
|
| 2010-06-22 15:36:25 |
Jeremy Foshee |
linux (Ubuntu): status |
Confirmed |
Invalid |
|
| 2010-07-11 17:38:46 |
John Rash |
bug |
|
|
added subscriber John Rash |
| 2013-12-02 15:39:13 |
bananenkasper |
removed subscriber bananenkasper |
|
|
|
| 2017-04-12 08:57:14 |
mikbini |
bug |
|
|
added subscriber mikbini |
