AMD64 system slow/unresponsive during disk access (Part 2)

timeBandit

Continuation of AMD64 system slow/unresponsive during disk access....

For convenience, in case this changeover happened in mid-conversation, the above link refers to the last page of the prior topic, not the first.
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

joi_ · Apprentice Joined: 28 Mar 2005 Posts: 171

there's a new thread at LKML about responsiveness under I/O load
http://lkml.org/lkml/2009/9/19/288
speak up there people!

lagalopex · Guru Joined: 16 Oct 2004 Posts: 565

I tried the BFS scheduler, but my usb system would afterwards not recognize any new devices.
So I have to wait a bit longer...

In the lkml thread they mentioned:

kernelOfTruth · Posted: Mon Sep 21, 2009 1:43 pm Post subject:

kernelOfTruth · Posted: Thu Sep 24, 2009 10:02 pm Post subject:

all of those recommendations of extremly lowering numbers of dirty_background_ratio, dirty_ratio, quantum, etc. seems to have made it magnitudes more worse !

some new stuff:

1) for this to work you need to switch to CFQ (if you use zen-sources or a kernel which has support for BFQ, better use that)

mamunata · Apprentice Joined: 30 Nov 2004 Posts: 169

I follow this topic for a while, because I have a laptop with Turion64 CPU and 64bit gentoo on it, and I/O performance is terrible - system load increases to 10 or even 15-20 on heavy disk usages and system is completely unusable.
I've been impressed that there's different "tricks" that decrease the problem and lot of them are for SATA (sd*) hard disks (with or without NCQ), but my laptop is with IDE hard disk and problem is fully present.
So am I missing something or problem is independent of hard disk type and is inherent for all types HDD?

Elv13 · Posted: Sat Sep 26, 2009 8:20 pm Post subject:

Try the kernel 2.6.30-rc5, it is a version just after a patch that really worked well and a redesign that broke it again. I use sata drives, but it may work for you too.

sidamos · Apprentice Joined: 16 Dec 2007 Posts: 246

I am having the same problem since 2.6.30 and I also do not have SATA. 2.6.29 works better. But this is not fixed in 2.6.31, as far as I understood.

kernelOfTruth · Posted: Sun Sep 27, 2009 2:53 pm Post subject:

sidamos · Apprentice Joined: 16 Dec 2007 Posts: 246

krinn · Watchman Joined: 02 May 2003 Posts: 7470

Cyker · Veteran Joined: 15 Jun 2006 Posts: 1746

nero37 · Posted: Mon Sep 28, 2009 11:40 am Post subject:

lagalopex · Guru Joined: 16 Oct 2004 Posts: 565

Anybody else running bfs?
I am currently running a 2.6.31.1 with the bfs-240 patch applied.
It now works for me and is pretty responsive as far as I can tell

kernelOfTruth · Posted: Wed Sep 30, 2009 4:50 pm Post subject:

lagalopex · Guru Joined: 16 Oct 2004 Posts: 565

With bfs240 I had again a keyboard issue. So I switched to 2.6.32-rc1 as stated in Kernel 2.6.30/31 desktop interactivity patch (no BFS) some improvements for cfs got merged in mainline. Its imo better...

bfs300 is now available... will try it the next days...

Update: Now with bfs302 as the 300 still had a keyboard issue for me. ck noted that switching to evdev helps... I will see...

Update2: bfs303 and ck ran a new test against vanilla-2.6.32-rc3. The rc is doing well

MageSlayer · Posted: Sun Oct 11, 2009 7:04 am Post subject:

I confirm that problem with keyboard under Xorg + bfs has gone after switching to evdev.
evdev 2.1.3 version is the only one which does not have buggy keys repetition though.

Lepaca Kliffoth · Posted: Mon Oct 12, 2009 7:29 pm Post subject:

BFS solves the problem completely for me. It doesn't make it better; under the kind of loads that used to still create problems even with the few kernel versions that were better, the mouse jerkiness and frame skipping in videos simply doesn't appear.

Things that used to be problematic and now are fine:

- copy stuff over SMB
- check out linux git sources
- paludis -s

It is now impossible for me to reproduce the problem.

I'm using the latest zen-sources.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox!

Sujao · l33t Joined: 25 Sep 2004 Posts: 677 Location: Germany

forkboy · Posted: Wed Oct 21, 2009 10:42 pm Post subject:

wazoo42 · Apprentice Joined: 13 Apr 2004 Posts: 165

They are available in portage (my portage tree shows .31-r4 is the latest one), as well as from the overlay, zen-sources. I found BFS helps, but I'm not sure it eliminated the problem. Then again, I haven't done any sort of concrete testing...

Sujao · l33t Joined: 25 Sep 2004 Posts: 677 Location: Germany

... no can't be true ....

.....

...

....

...

Oh my God. It actually seems to work. I tried out the things that were annoying me for almost 2 years now and my system remained responsive. Usually when I write a big (>5GB) file with mmg to harddrive or copy them click response time in most applications is between 10-30s. mmg window doesn't get refreshed until its finished after several minutes and videos don't play proberly. Now I can surf easily with firefox, even play a movie with no visible delay and the mmg window is updating as expected. I'll report back if something changes....I still can't really believe that this is true.

EDIT: It's a shame the vanilla kernel doesn't accomplish this. Thanks to the ZEND Guys! I love you right now!

EDIT2: Moving a 8GB file still increases the response time of applications. For example smplayer open file dialog reacts after 3-4s but this is acceptable. Still much better then 30s. And video still plays smoothly.

mamunata · Apprentice Joined: 30 Nov 2004 Posts: 169

kernelOfTruth · Posted: Wed Oct 28, 2009 6:10 pm Post subject:

Sujao · l33t Joined: 25 Sep 2004 Posts: 677 Location: Germany

Well it's not as good as in the first test. This time I had to hash a ~6GB file and there were big delays. I had a flashvideo in firefox running and another movie in PAL and the hash. Firefox didn't react to clicks for more than 1min until the hash was finished, the flash video ran with no problems, the movie stopped about every 15s for 1-2s but i think with the old kernel it was much worse, the movie would freeze completely and run for 1-2s every 15s.

Overall it seems to be better but I didn't make any identical benchmarks. I simply try things that used to lock my system. So maybe my first test was somehow different and that is why it ran so flawlessly.

My kernel configuration (The forum doesn't seem to accept such a long text):
http://pastebin.com/f78f5fec1

EDIT:

CONFIG_CPU_BFS_AUTOISO=y was not set for me, recompiling at the moment. What does it do exactly? Almost no help available. Scheduler for the X-Server?
Code:

for i in /sys/block/sd*; do
/bin/echo "bfq" > $i/queue/scheduler
done

Was not necessary for me. All drives have the same output:
Code:

# cat /sys/block/sda/queue/scheduler
noop fifo anticipatory deadline cfq vr [bfq]
mamunata wrote:

I've noticed (but not 100% sure) that if I leave my PC alone, and not working on it for a couple of hours, when I get back the PC is very slow.

I think this is not caused by a faulty IO scheduler. I have the same behaviour. I think the RAM is simply cleaned of not accessed desktop applications and when you come back it needs to reread libraries from the harddrive. Can anyone confirm that?

EDIT2: OK, seriously..

.... Sorry guys. This is the second time I thought the problem was kind of solved. Now, I did three "comparable" benchmarks with my old 2.6.30-gentoo-r1(1), linux-2.6.31-zen4 CONFIG_CPU_BFS_AUTOISO=n(2) and linux-2.6.31-zen4 CONFIG_CPU_BFS_AUTOISO=y(3). The benchmark: Dumping a file from hdd A to hdd B, vieweing a movie from hdd A and hdd C, viewing the same flashvideo and hashing a file from hdd A and hdd B with sha256sum.

The result (just my subjective perception): 2 and 3 makes no difference, 1 is a little worse, but not as worse as I would have expected. I think I need a more detailed automatic benchmark with measurable results to make further statements, as my previous claims turned out to be false.