AMD64 system slow/unresponsive during disk access...

engineermdr · Posted: Fri Jun 29, 2007 4:25 am Post subject:

devsk wrote:

devsk · Posted: Fri Jun 29, 2007 4:43 am Post subject:

engineermdr · Posted: Fri Jun 29, 2007 5:13 am Post subject:

I don't know if it makes any difference, but I set deadline as my default scheduler instead of writing it to the sysfs locations. And I'm also running gentoo-sources-2.6.21-r3.

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

opentaka · l33t Joined: 18 Feb 2005 Posts: 840 Location: Japan

thanks, using deadline as a scheduler solved in my case.
_________________
"Being defeated is often a temporary condition. Giving up is what makes it permanent" - Marilyn vos Savant

likewhoa · Posted: Fri Jun 29, 2007 8:13 pm Post subject:

using deadline scheduler makes no difference here either, maybe people should stress their systems a bit more.

engineermdr · Posted: Fri Jun 29, 2007 8:31 pm Post subject:

node@are-b.org · n00b Joined: 20 Apr 2005 Posts: 44

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

likewhoa · Posted: Tue Jul 03, 2007 8:21 am Post subject:

likewhoa · Posted: Thu Jul 05, 2007 6:17 pm Post subject:

UPDATE:

everything is fixed now with MASKED cdrtools package. app-cdr/cdrtools-2.01.01_alpha27

no longer does my system freeze up on mkisofs runs. I assumed from the beginning it was something else, like
the scheduler and or the sata driver but all this time it was mkisofs but the scheduler also made a difference as i'm now
using the deadline scheduler which performs better than the rest. If you're having problems even after using the
above cdrtools package and are using deadline scheduler then your problems are unknown as of now. I should have known
to try another cdrtools package but originally I did and downgrade from the current MASKED app-cdr/cdrtools-2.01.01_alpha27 to
app-cdr/cdrtools-2.01.01_alpha25 and still experienced the problems, but it was the use of the scheduler along with the alpha27 cdrtools
package that seems to be working so for me.. I have burned 6 DVDs so far with it and my system is very responsive,.. new terminal windows open
on time or with a slight 1sec delay but that's better than 5-7 seconds like others are experiencing.. anyways,.. here are some screenshots of
my last mkisofs run with 'dstat -vfa' output. as you will notice mkisofs kind of paused for a second or so this happent several times but didn't stop me from doing other stuff also I/O status was zero for two drives too.

2007-07-05_1600x1200.png

latest run while compiling openoffice,running boinc,beryl,firefox,evolution, and downloading pr0n at the same time, while playing some music could not slow my system down. so it's to my conclusion that current cdrtool's mkisofs was the problem. I will file a bug next.

2007-07-05-05_1600x1200_1.png

Shamus397 · Apprentice Joined: 03 Apr 2005 Posts: 218 Location: Ur-th

I've been following this thread with interest for some time. I have an AMD64 processor in my work machine and for the longest time was running it as x86. Then, around ten months or so ago, I decided to take the plunge and convert it over to amd64 and to be honest it didn't seem all that much faster to me. And of course all along I've been experiencing the slowdowns with the SATA (now back to IDE) disk access mentioned at the beginning of this thread. And I've tried all the suggestions and none of them have done any good (including the system/kernel tuning thread found here).

I've had the deadline queue hard compiled into my kernel for some time now and while upgrading from 2.6.18-gentoo-r3 to 2.6.21-gentoo-r3 helped some, it doesn't help at all when the kernel starts swapping. It's frustrating to see the CPU hover around 10% utilization while the disk thrashes around 1-2 MB/s (according to gkrellm). When that happens, all bets are off--the system is unresponsive (wonder why?

) and unusable. And yes, DMA is turned on: Doing three quick hdparm tests yields around 627-639 MB/s for cached reads and 36-58 MB/s for buffered reads.

Judging from the length of time this thread has been around it would seem that amd64 isn't going to be well supported for some time, if at all, since the kernel devs clearly don't seem to care about it. I'm scratching my head trying to think if I've missed anything, but I don't think so. I could be wrong about that.

At any rate, I'm seriously considering switching back to x86. At this point, all the whizzyness of running 64 bit seems to be counterproductive to the task of running a desktop.

Some stats: 512M RAM, 2.5G swap, AMD Athlon 64 3200+ running at 2GHz.

lagalopex · Guru Joined: 16 Oct 2004 Posts: 562

Have you tried the app-cdr/cdrkit, the gpl-fork of app-cdr/cdrtools?

likewhoa · Posted: Fri Jul 06, 2007 9:48 pm Post subject:

likewhoa · Posted: Fri Jul 06, 2007 9:48 pm Post subject:

Shamus397 · Apprentice Joined: 03 Apr 2005 Posts: 218 Location: Ur-th

likewhoa · Posted: Sat Jul 07, 2007 5:00 am Post subject:

piwacet · Guru Joined: 30 Dec 2004 Posts: 486

My system is essentially unusable when it is forced to swap, otherwise it's essentially fine. It's hard to ascribe slowness when swapping to anything other than the actual swapping itself because access to hard disk is orders of magnitude slower than access to memory. Everything seems slow, opening menus in firefox, etc, presumably because the code for doing that is swapped out. If I'm doing an emerge, CPU usage goes to near zero because the system is so busy bringing pages in and out of memory, it doesn't actually have the date in memory for the cpu to work on. I apologize for not reading this page of the thread closely, but if one's only problem with slowness occurs during periods where swap is required, most likely the best solution is simply more ram.

digitized · Posted: Sun Jul 08, 2007 3:55 pm Post subject:

Sorry but in my eyes your answer is somehow shortsigthed as well as the one with mkisofs. Why searching for the root of that problem when you can just fix some of its results?
OK, more RAM is always usefull but that doesn't help you when it comes to heavy i/o on your fixed or removeable storage (where swapping is one of those things). I'm watching my system doing a slideshow with a moving frame every 1 to 60 seconds while doing heavy network and disk i/o. Thats neither acceptable nor usable but I've to live with that until it's fixed.
I've tried many things mentioned in this thread, lkml or kernel's bugzilla but so far nothing changed it. Downgrading back to before the bug appeared in kernel is not an option because my hardware started working with 2.6.19+.
The strange thing is, I've compared my kernel config with one of a friend of mine, there are no significiant differences between our configs but he insists not having this problem.

likewhoa · Posted: Sun Jul 08, 2007 9:25 pm Post subject:

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

digitized · Posted: Mon Jul 09, 2007 1:49 pm Post subject:

For my SATA systems disabling NCQ didn't make much a difference and my SATA-RAID Controller doesn't support NCQ.
I've also experienced that cfq is more usable than deadline, noop or anticipatory. CFQ just slows down everything (high I/O wait, very short locks) while the others lock my system completely (slightly less i/o wait than cfq but long locks).

piwacet · Guru Joined: 30 Dec 2004 Posts: 486

With regard to the swap issue, I suppose one could argue that system slowness when using swap could be due to bugs related to I/O; I have just assumed it was due to the actual swapping itself because access to swapped pages is orders of magnitude slower than access to pages in memory, and my system never has slowdowns under heavy I/O, except when that I/O is because the memory is maxed and the system is swapping.

Shamus397 · Apprentice Joined: 03 Apr 2005 Posts: 218 Location: Ur-th

I would fully expect things to be slower when pages are being swapped--that's not what I'm talking about. What I was talking about was the fact that it would swap and keep swapping for what seemed like an eternity. I tried to launch an app when it was in that state (Rosegarden 1.5.1) and I kid you not--it took well over a half hour for that thing to launch itself. And all the while the CPU would hover at around 10% utilization while the disk would thrash itself around 1-2Mb/s. This is not normal OR good, and I had (and still have) more than enough swap (around 5x RAM at the moment).

So, anyway, I've switched back to x86 (with the same kernel, filesystem, etc) and the system seems faster overall (anecdotal, but that's all I've got--it would be nice to see some empirical tests done, but I don't have the resources). With my normal pattern of use I have yet to experience the kind of slowdowns/thrashing that was a common experience while my system was running amd64. It seems to me to be a no brainer that amd64 is just not ready for primetime. Maybe if the kernel devs (or toolchain or whoever

) did their development on that architecture they would care about it more but it seems pretty obvious that that architecture is the red-headed stepchild.

Oh, and BTW, thanks for the heads up on conky. I'd never heard of it (and in truth, if I had, I would have thought it was yet another tired Konqueror doohicky

). With both gkrellm and conky running side by side, I see conky taking more CPU than gkrellm most of the time (I still like conky, though

).

nick88 · Posted: Tue Jul 17, 2007 1:28 pm Post subject:

Hi, I've been reading this thread a bit and I'm seeing I think a similar problem when I use nuvexport on my x86 setup. I've tried to change my kernel to 2.6.22 (kernel.org), turn off pre-emption and change to the deadline scheduler w/o success. When I changed the swapiness to 20 (from 60) the responsiveness improved and with dstat, I saw a reduced amount of swap occur. However, I still see under some recordings my system (not all!) gets pegged to 100% whereas it used to run much better.

The following is my setup:

I'm running nuvexport (0.4_p20061203) and mythtranscode (mythtv version 0.20.1_p13344) on my AMD Athlon-XP 2600 w/ 2 GB of RAM on a nVidia nForce2 chipset based system.

I was starting to see this problem a few months ago and it didn't occur too often. I would record to a reiserfs partition and dump it to a ext3 partition either on my USB drive or to another PATA drive. I've also tried to rebuild ffmpeg and mythtv to see if that could be culprit, but no luck.

Does this problem belong in this thread or should I create a new one? I think the problems are related... DId I miss anything to try on the list?

Nick.