You are not logged in.
Pages: 1
Hiyas,
Ive made the switch from i686 to x86_64 and of course the first thing I did once I had gnome up and running was to "cp -R" all my old files back to my home dir, which basically stalled the machine until the copy had finished. This did not happen in i686 with exactly the same setup/kernel version.
I did some research and found gentoo and ubuntu threads raising the same issue, the ubuntu thread went into more detail basically stating that CFS with FAIR_SCHED enabled will stuff up your disk IO and that CGROUP_SCHED fixes the problem. I tried finding the FAIR_USER_CGROUP_SCHED option that they stated was necessary alleviate the problem, only to find it wasnt there.
http://forums.gentoo.org/viewtopic-t-48 … amd64.html
https://bugs.launchpad.net/ubuntu/+sour … bug/188226
I grabbed the Zen sources and built it with BFQ scheduler enabled (CFS still as default) and tested it with just the normal CFS with the default Arch config, which resulted in the same massive lockups with large disk transfers. Rebooted with elevator=BFQ and the problem is gone.
Seems strange no one else has commented on this issue it makes the system basically halt for heavy disk IO.
Anyway hope this helps someone, Ill have a play with the CGROUP stuff some more and post a diff in a bug report if I can get it sorted.
Offline
Seems the Ubuntu lot just like to use the wrong name for things, By CONFIG_FAIR_CGROUP_SCHED they seem to mean CONFIG_CGROUP_SCHED, anyway I rebuilt the kernel with the options below and it runs perfectly using CFS I/O scheduler, no more 100% thrash I/O waits on large disk to disk transfers, and no more application pauses on large same disk transfers.
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
# CONFIG_CPUSETS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_USER_SCHED is not set
CONFIG_CGROUP_SCHED=y
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
Offline
Put all this in a feature request in the bugtracker. It could very easily be overlooked here, but every bug report is read and evaluated.
Offline
Done, absolutely loving 64 bit btw, with that fixed is seems so much more responsive than i686, great job by the Devs
bug linky thing http://bugs.archlinux.org/task/10512
Offline
I found this post after posting about the same issue, but with i686. so maybe this isn't just a x64 issue
Offline
this is definitely still an issue. i am experiencing this problem under x86-64.
*NOTE: The bug was closed yesterday, I have not tried high I/O after this bug was closed/latest kernel....
Last edited by elocal (2008-08-11 15:00:12)
Offline
this bug is still alive. i just did a fresh install, copying some files from my old /home to my new /home, the desktop becomes unresponsive when opening new applications (konqueror or openoffice for example). The mouse even lags a little bit, and opening menus is slower.
Offline
this bug is still alive. i just did a fresh install, copying some files from my old /home to my new /home, the desktop becomes unresponsive when opening new applications (konqueror or openoffice for example). The mouse even lags a little bit, and opening menus is slower.
Ok, somehow I decided to compare Arch(x86_64) with 32-bit and 64-bit ubuntu 8.04. 64-bit ubuntu performed WAY WORSE, lagging really bad. 32-bit ubuntu performed about the same except that there was no mouse lag.
So I think this lag is normal behavior due to high IO activity on the same drive as the root(/). Not going to lie though, Windows Vista IO Scheduler provides better interactivity than the CFQ in mainline. WHERE THE HELL IS CON KOLIVAS?!? I remember ck-sources being really awesome on situations like this...
Offline
For me at least, the problem seemed to compound when kernel 2.6.26 came into Core. The behavior is identical on 686 and x86_64, even my network started misbehaving with high i/o.
Intrepid (adj.): Resolutely courageous; fearless.
Offline
Pages: 1