You are not logged in.
Oh, seems like I missed this thread... I have this issue as well, my system goes to its knees, when for example I copy data from my internal jfs-formatted notebook harddrive to my xfs formatted external harddrive. The CPU load is really low, around 10% or so, so that doesn't seem to be the culprit, but it could happen to take several minutes to simply close an application!
I have a single core CPU with 1,7GHz
Last edited by Army (2009-02-16 15:39:25)
Offline
Maybe you guys have the issue described here
wow thanks for the link. i had read another guide related to swappiness, and they suggested setting at 10. setting at 1 massively improved the performance on my core2quad. it's amazing. thanks!
"I know what you're thinking, 'cause right now I'm thinking the same thing. Actually, I've been thinking it ever since I got here:
Why oh why didn't I take the BLUE pill?"
Offline
I'm pretty sure it's cause of the Ingo Molnar's Completely Fair Scheduler. I don't remember this happening before, but can't be sure
If i copy 50GB of files from one SATA 7200rpm ext3 drive to another, all apps are excruciatingly slow (including firefox, nautilus etc..) until the copying is finished
whereas non-linux kernels (vista, OS X etc..) don't have this issues.
In vista, firefox seems pretty responsive even while copying.has anyone else noticed?
Is your SATA disk recognized as ATA or SCSI in linux? Such a problem usually happens when ATA hd is in PIO mode, in which the DMA is disabled and disk access consumes a lot of CPU resource.
Generally XFS should offer the best performance when nobarrier option is used, but the choice of filesystem and IO scheduler should be unrelated to your problem I believe.
Offline
with xfs use deadline I/O scheduler
optimize formating flags:
for example
mkfs.xfs -l version=1,internal,size=128m -i size=2048 -d agcount=2 -f /dev/sdX
xfs likes big log files, does not lime barriers (which nowadays is not a problem)
I/O scheduler should be selected for specific fs and tasks.
there is interesting disscussion at lkml about constant (useless?) tweaking of I/O scheduler code vs file system
Offline
A patch that may help: http://bugzilla.kernel.org/attachment.cgi?id=20172
That, the swappiness setting, and the cache pressure setting, should help. I found an older patch from Con Kolivas to autoregulate the swappiness setting, but it doesn't patch on recent kernels and I don't have the skills to make it work (or faith that it is still relevant).
Original message: http://lkml.org/lkml/2003/10/23/53
Fixed patch: http://lkml.org/lkml/2003/10/25/4
I also found this: http://ck.kolivas.org/patches/swap-pref … h-41.patch
With explanation here: http://lwn.net/Articles/153353/
Offline
A patch that may help: http://bugzilla.kernel.org/attachment.cgi?id=20172
That, the swappiness setting, and the cache pressure setting, should help. I found an older patch from Con Kolivas to autoregulate the swappiness setting, but it doesn't patch on recent kernels and I don't have the skills to make it work (or faith that it is still relevant).
Original message: http://lkml.org/lkml/2003/10/23/53
Fixed patch: http://lkml.org/lkml/2003/10/25/4I also found this: http://ck.kolivas.org/patches/swap-pref … h-41.patch
With explanation here: http://lwn.net/Articles/153353/
taken from the patch refernce page ( http://bugzilla.kernel.org/show_bug.cgi?id=12309 ):
Does not seem to fix the latency problem though.
Offline
Yes. It does mitigate the damage, though.
Offline
Hi, any tip for fix this? i move from a sata to another using mc , and the machine turn really slow....any more tips is really welcomed..
Offline
I already said this in another thread but I'll say it again in this one
I managed to get decent performance with the anticipatory scheduler
(used as default in kernel <=2.6.18 - enable it by 'echo anticipatory > /sys/block/$devicename/queue/scheduler'
as root and add 'elevator=as' to your menu.lst) and adding noatime to fstab...
Last edited by Rehto (2009-04-18 08:18:50)
Offline
I already said this in another thread but I'll say it again in this one
I managed to get decent performance with the anticipatory scheduler
(used as default in kernel <=2.6.18 - enable it by 'echo anticipatory > /sys/block/$devicename/queue/scheduler'
as root and add 'elevator=as' to your menu.lst) and adding noatime to fstab...
Thanks, I will definitely try that out, and by <=2.6.18 do you mean >=2.6.18?
Offline
I meant 2.6.18 and older kernels
Offline
I have .19 and it does say anticipatory in the scheduler file.
EDIT:
$ cat scheduler
noop anticipatory deadline [cfq]
Last edited by Procyon (2009-04-18 11:44:08)
Offline
The first few words there are schedulers you _can_ use. The one in brackets is the one you _are_ using.
Offline
I haven't notice this much on Arch, but at work I have Ubuntu 9.04 ext4, the comp almost slows down even while copying from one directory to another on the same hard disk. Seems to be more pronounced in ext4.
Offline
A patch _some_ are saying helps, should apply to 2.6.31-rc5 and possibly lower. If anyone wants to try..? I cannot right now.
Offline
A patch _some_ are saying helps, should apply to 2.6.31-rc5 and possibly lower. If anyone wants to try..? I cannot right now.
I applied the patch to -rc5 and booted up with cfq and tried
dd if=/dev/zero of=/tmp/test bs=1M count=1M
and it was just as bad and definitely seemed worse than my previous straight deadline setup.
I use ext4 on all my desktop HDD's
Offline
I have seen somewhere (can't remember where now) that for people with sata HDs the deadline scheduler would help a bit, that's what I am using now and I don't see my pc crawling to a halt but it is possible to notice a certain slowdown.
I'm running with 4G ram, no swap an no extra patches.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
http://bbs.archlinux.org/viewtopic.php?id=71131 <--- another thread describing this problem
Last edited by graysky (2009-08-07 19:43:48)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Im using zen patch set and CFQ and dont have this problem anymore (or as bad as it was)
Offline
I'm also affected by this, and I now really had a chance to test some changes
I started doing a partition conversion on a 500gb partition with convertfs and it pretty much froze the system and it took like 2 hours just issue these two things (the conversion is still going while I'm writing this so at least the desktop is usable now):
1 . Change to deadline scheduler
echo deadline > /sys/block/sda/queue/scheduler
echo deadline > /sys/block/sdb/queue/scheduler
2. Start ioReniceD ( http://bbs.archlinux.org/viewtopic.php?id=73359 )
The difference is huge. From unusable to slight lagginess
EDIT: Oops, I'm not sure does ioreniced require cfq. But I actually started it before changing the scheduler
Last edited by Beini (2009-09-03 12:07:11)
archlinux x86_64 user || My PKGBUILDs
Offline
Offline
This is a CPU scheduler though, does it really fix the I/O problems ?
I seem to remember Con was also working on I/O interactivity at some point, but I was not yet able to find back any materials.
Edit : he is reporting himself the very same problem in http://ck.kolivas.org/german_linux_maga … erview.txt :
Disk I/O is a disaster for the desktop. Most other hardware gets faster
exponentially, yet hard disks are still based on a 50 year old design and are
only getting faster and fatter at a linear rate. This means they are becoming
_relatively_ slower and slower. Anything we do that can avoid and minimise
disk I/O will help. Write a very large file to (one) disk and see what else
you can do on your desktop while this is going on.
Last edited by shining (2009-09-03 17:16:54)
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Sophotect wrote:This is a CPU scheduler though, does it really fix the I/O problems ?
I seem to remember Con was also working on I/O interactivity at some point, but I was not yet able to find back any materials.
Edit : he is reporting himself the very same problem in http://ck.kolivas.org/german_linux_maga … erview.txt :
Disk I/O is a disaster for the desktop. Most other hardware gets faster
exponentially, yet hard disks are still based on a 50 year old design and are
only getting faster and fatter at a linear rate. This means they are becoming
_relatively_ slower and slower. Anything we do that can avoid and minimise
disk I/O will help. Write a very large file to (one) disk and see what else
you can do on your desktop while this is going on.
It's an IO scheduler, not a CPU scheduler.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Hell yeah!! Can't wait to try this out.
And Zariel, the Zen patchset includes the patch I mentioned actually
Offline
shining wrote:Sophotect wrote:This is a CPU scheduler though, does it really fix the I/O problems ?
I seem to remember Con was also working on I/O interactivity at some point, but I was not yet able to find back any materials.
Edit : he is reporting himself the very same problem in http://ck.kolivas.org/german_linux_maga … erview.txt :
Disk I/O is a disaster for the desktop. Most other hardware gets faster
exponentially, yet hard disks are still based on a 50 year old design and are
only getting faster and fatter at a linear rate. This means they are becoming
_relatively_ slower and slower. Anything we do that can avoid and minimise
disk I/O will help. Write a very large file to (one) disk and see what else
you can do on your desktop while this is going on.It's an IO scheduler, not a CPU scheduler.
How can you be so confident in writing non-sense ?
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline