| View previous topic :: View next topic |
| Author |
Message |
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
 Posted: Mon Aug 13, 2007 5:54 am Post subject: Desktop responsiveness while heavy IO loads |
 |
|
I'm having very unresponsive system during specific IO operations, like coping/moving large files. Would be really nice if somebody else share own experiences about this issue. Just make a simple test: copy ~4Gb file to another location on the same local drive where is your system installed and at the middle of this operation try to run any program like kword/konqueror/gimp and see how long it takes. Please post you system specifications as well (kernel, filesystem, amount of memory/swap, IO/CPU scheduler, hardware...). Here's mine:
| Code: | kernel: vanilla 2.6.22 + cfs(v19)
IO scheduler: CFQ
filesystem: ext3
mem/swap: 2Gb/2Gb
CPU: Core2Duo 6300@2800
HDD: SATA 250Gb (Maxtor 6V250F0) |
Last edited by VoVaN on Tue Aug 14, 2007 6:54 am; edited 3 times in total |
|
| Back to top |
|
 |
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Mon Aug 13, 2007 6:00 am Post subject: |
|
|
well - I/O is a common problem as the CPU has to wait for the disc to get the required data...
You may want to try the ck-sources as Con was working on that problems. The CFQ Scheduler is another possibility to get the system more responsive under such conditions.
Rei
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Mon Aug 13, 2007 6:10 am Post subject: |
|
|
| ToeiRei wrote: | well - I/O is a common problem as the CPU has to wait for the disc to get the required data...
You may want to try the ck-sources as Con was working on that problems. The CFQ Scheduler is another possibility to get the system more responsive under such conditions.
Rei |
I agree with you, but the impact on the performance is way too high IMO. Normally gimp starts in ~5 seconds but if I would copy a large file it could be 40sec... and konqueror normally starts in a couple of seconds but in my test it takes more then minute(!). Actually I'm having the same problem with ck sources as well and my IO scheduler is CFQ (that was a typo in my post which is corrected already). |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Mon Aug 13, 2007 6:21 am Post subject: |
|
|
| ToeiRei wrote: | well - I/O is a common problem as the CPU has to wait for the disc to get the required data...
You may want to try the ck-sources as Con was working on that problems. The CFQ Scheduler is another possibility to get the system more responsive under such conditions.
Rei |
Could you run the test I ask in my original post? |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Mon Aug 13, 2007 6:32 am Post subject: |
|
|
I have generated a 4 GB File and I am currently moving it around on my disc.
Firefox opens 3 seconds slower than usual.
Linux unstable 2.6.22-rei-r2 #1 SMP Mon Jul 30 17:00:01 CEST 2007 i686 Genuine Intel(R) CPU T2500 @ 2.00GHz GenuineIntel GNU/Linux
1 GB RAM, 2 GB swap, CFQ Scheduler, some patches from ck, XFS
Rei
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Mon Aug 13, 2007 7:36 am Post subject: |
|
|
| ToeiRei wrote: | I have generated a 4 GB File and I am currently moving it around on my disc.
Firefox opens 3 seconds slower than usual.
Linux unstable 2.6.22-rei-r2 #1 SMP Mon Jul 30 17:00:01 CEST 2007 i686 Genuine Intel(R) CPU T2500 @ 2.00GHz GenuineIntel GNU/Linux
1 GB RAM, 2 GB swap, CFQ Scheduler, some patches from ck, XFS
Rei |
Did you sync, flush caches ( echo 1 >/proc/sys/vm/drop_caches) and close Firefox _before_ starting the test? |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Mon Aug 13, 2007 7:41 am Post subject: |
|
|
even did a complete reboot for you...
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
baeksu
l33t
Joined: 26 Sep 2004
Posts: 609
Location: Seoul, Korea
|
| Posted: Mon Aug 13, 2007 7:49 am Post subject: |
|
|
I had a similar (I think) issue on a 2.6.22 kernel with cfs patch. Heavy i/o would completely block off any new disk access. I could move the mouse alright, but I wouldn't be able to open new windows for 10-20 seconds at a time.
I switched back to a ck-patch, and the problems went away.
My specs are pretty much the same with yours: Core2Duo E4400, 2GB mem, cfq io-scheduler, ext3 filesystem.
My first impressions of cfs were not good. I hope it improves before the release of 2.6.23, or that someone picks up Con's work.
I'll do a test run with a 4GB file when I get to home to my machine.
_________________
Gnome:
1. A legendary being.
2. A never ending quest to make unix friendly to people who don't want unix and excruciating for those that do. |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Mon Aug 13, 2007 7:53 am Post subject: |
|
|
| ToeiRei wrote: | | even did a complete reboot for you... |
Thank you  |
|
| Back to top |
|
|
Dralnu
Veteran
Joined: 24 May 2006
Posts: 1919
|
| Posted: Mon Aug 13, 2007 2:45 pm Post subject: |
|
|
May or may not help any, but have you run a test w/ hdparm to see if it might be a setting there that might be slowing you down?
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner. |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Mon Aug 13, 2007 3:09 pm Post subject: |
|
|
| Dralnu wrote: | | May or may not help any, but have you run a test w/ hdparm to see if it might be a setting there that might be slowing you down? |
If you mean "did I run hdparm for my drive", then yes and it looks fine, transfer speed is about 65Mb/s and there's not that much to tweak for a SATA drive. |
|
| Back to top |
|
|
foolosophy
n00b
Joined: 13 Apr 2006
Posts: 50
Location: Buenos Aires, Argentina
|
| Posted: Tue Aug 14, 2007 2:13 am Post subject: |
|
|
I didn't do the test, but that used to happen to me recently, because I had not loaded DMA properly, but, since you have a SATA drive, I doubt that you are suffering the same problem.
I don't know much about it, but I can suggest using ionice when doing that kind of big copies. (It's like the nice process scheduler, but instead for CPU, it's for I/O). Google for it.
Do you find the CFQ scheduler better than the "Anticipatory"? I have compiled the kernel with the three of them, but with "Anticipatory" as default.
When I finish updating KDE (fuck expat, by the way), I'll do your test. |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Tue Aug 14, 2007 6:53 am Post subject: |
|
|
| ToeiRei wrote: | I have generated a 4 GB File and I am currently moving it around on my disc.
Firefox opens 3 seconds slower than usual.
Linux unstable 2.6.22-rei-r2 #1 SMP Mon Jul 30 17:00:01 CEST 2007 i686 Genuine Intel(R) CPU T2500 @ 2.00GHz GenuineIntel GNU/Linux
1 GB RAM, 2 GB swap, CFQ Scheduler, some patches from ck, XFS
Rei |
Do you have system installed on a separate harddrive? |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Tue Aug 14, 2007 7:29 am Post subject: |
|
|
The box we're talking about is my laptop with just one SATA disc in it...
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
dizzy
n00b
Joined: 04 Aug 2002
Posts: 50
Location: Melb.OZ.Terra.Sol
|
| Posted: Tue Aug 14, 2007 9:30 am Post subject: |
|
|
I don't know if you guys are aware of this thread https://forums.gentoo.org/viewtopic-t-482731.html
Seems like this problem has been around for a while, and only affect some people, regardless of whether you run amd64 or not. The last few posts also mentioned someone from OpenSuse and Debian with the same problem.
There are some solutions there for you to try if you haven't. Good luck. |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Tue Aug 14, 2007 2:54 pm Post subject: |
|
|
| dizzy wrote: | I don't know if you guys are aware of this thread https://forums.gentoo.org/viewtopic-t-482731.html
Seems like this problem has been around for a while, and only affect some people, regardless of whether you run amd64 or not. The last few posts also mentioned someone from OpenSuse and Debian with the same problem.
There are some solutions there for you to try if you haven't. Good luck. |
Thank you for the link. I tried to follow all discussions there as well as read some external links on bugzilla. I sounds like a lot of people are having this problem since kernel 2.6.18, but there's no real solution just some semi-working workarounds.... still... too bad. |
|
| Back to top |
|
|
rsevero
n00b
Joined: 01 Sep 2004
Posts: 33
|
| Posted: Tue Aug 14, 2007 9:16 pm Post subject: Re: Desktop responsiveness while heavy IO loads |
|
|
| VoVaN wrote: | | I'm having very unresponsive system during specific IO operations, like coping/moving large files. |
In a completely different front, do you have noatime on all your local mounts? If not, you should.
See http://kerneltrap.org/node/14148 for the complete history. |
|
| Back to top |
|
|
Ssl
Apprentice
Joined: 21 Feb 2003
Posts: 178
Location: Serbia
|
| Posted: Tue Aug 14, 2007 11:59 pm Post subject: |
|
|
VoVaN: Thank you for starting this story. I am having problem you described for years and seeing a lot of other people in gentoo/linux land complain on the same topic. But seems no one for all these years made a decent Desktop 'subsystem' that control cpu and i/o operations that do something soooo simple:
- If I click on one particular icon or launch menu item I want it as soon as possible to be visible and usable - as load time is something that matters the most!
Waiting for OpenOffice to load ~ 15sec, waiting for Firefox/Epiphany to load 6 sec, GIMP about 10sec and multiply it with 2x or 3x factor when some I/O operations are on in the background just makes it clear that a lot of engineering and programming is needed in Linux land and that current state is far from perfect.
Disappointed more seeing your system is far far better than mine (p4 cpu, ata100 disk) which I blamed for this performance disaster... Maybe the right topic for all this is "Broken Desktop Experience in Linux"... Do you think there are projects that are working in solving this?
And no, it is not DMA disabled and not kernel source unappropriate for Desktop usage... |
|
| Back to top |
|
|
VoVaN
l33t
Joined: 02 Jul 2003
Posts: 688
Location: The Netherlands
|
| Posted: Wed Aug 15, 2007 5:33 am Post subject: |
|
|
| Ssl wrote: | VoVaN: Thank you for starting this story. I am having problem you described for years and seeing a lot of other people in gentoo/linux land complain on the same topic. But seems no one for all these years made a decent Desktop 'subsystem' that control cpu and i/o operations that do something soooo simple:
- If I click on one particular icon or launch menu item I want it as soon as possible to be visible and usable - as load time is something that matters the most!
Waiting for OpenOffice to load ~ 15sec, waiting for Firefox/Epiphany to load 6 sec, GIMP about 10sec and multiply it with 2x or 3x factor when some I/O operations are on in the background just makes it clear that a lot of engineering and programming is needed in Linux land and that current state is far from perfect.
Disappointed more seeing your system is far far better than mine (p4 cpu, ata100 disk) which I blamed for this performance disaster... Maybe the right topic for all this is "Broken Desktop Experience in Linux"... Do you think there are projects that are working in solving this?
And no, it is not DMA disabled and not kernel source unappropriate for Desktop usage... |
I agree with you and thank you for undersanding the actual problem instead of suggesting posting hdparm -Tt or checking kernel parameters, preemption or .... I'm experienced enough to try all visible ways solving the problem _before_ posting here. I've seen a few posted bugs about this issue on bugzilla with hundreds replays more then a year old (!!!) and they aren't fixed yet... or still.... whatever. But in other hands, I wouldn't say it's "Broken Desktop Experience in Linux", simply because it's very responsive even under heavy CPU/IO loads except the problem with relatively large files I mentioned. I can easy "cp -ar / /mnt/backup" and do whatever I like without any problems, but If I would "dd if=/mnt/dvd of=/path/to/file.iso" the whole system will be almost unusable. Some tunable parameters like disabling NCQ and adjusting vm.vfs_cache_pressure are making things a _bit_ better, but still... I thing that's a big problem. |
|
| Back to top |
|
|
|
Desktop Environments
