I wrote:
>> When I do anything that causes a lot of I/O to the IDE
>> hard disk on a computer running 2.3.99-pre6, the system becomes
>> very unresponsive. I often have to wait a couple of seconds
>> for characters to echo on xterm windows, for example.
>> 2.3.99pre6-5 did not have this problem. I did not try
>> 2.3.99pre6-6 or 2.3.99pre6-7, so the problem could have been
>> introduced at that point too.
>> I have verified that the problem is triggered by IO rather
>> than CPU utilization.
Trond Myklebust <trond.myklebust@fys.uio.no> immediately responded:
>Does the following cure it?
>Cheers,
> Trond
>--- linux-2.3.99-pre6/fs/buffer.c Wed Apr 26 02:28:55 2000
>+++ linux-2.3.99-pre6-devel/fs/buffer.c Thu Apr 27 13:27:52 2000
>@@ -2417,7 +2417,8 @@
>
> int block_sync_page(struct page *page)
> {
>- run_task_queue(&tq_disk);
>+ if (!Page_Uptodate(page))
>+ run_task_queue(&tq_disk);
> return 0;
> }
>
Sorry for taking two days to report the results of your
patch. No, this patch does not completely fix the problem. I
have let a large build process run on this machine for the past
six hours with your patch, and it has still gotten only about half
as far as far as it usually gets in that time. kswapd has
accumulated over three CPU hours of runtime in that time, even
though the machine has only been up for eleven and a half
hours. The machine has 512MB of RAM and there is very little
parallelism in the build process that it is running. It
has plenty of memory available.
Rik van Riel <riel@conectiva.com.br> also kindly responded very
quickly:
>It may have been introduced with the new memory management
>code I wrote. I don't think so since I haven't been able to
>reproduce the problem here (in fact, my test box is more
>resilient against heavy IO than before), but it may be that
>your workload is very different from mine, or that your IDE
>disk has very long seek times...
The disk on this particular machine is a 5400RPM 27GB
IDE Maxtor drive with DMA activated and most other features
turned off. Here are its hdparm settings:
/dev/discs/disc0/disc:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 52755/16/63, sectors = 53177040, start = 0
I find it difficult to believe that IO to the disk
is actually the issue when kswapd is apparently _running_ for
over 25% of the available CPU cycles.
>Could you provide me with a bit more details, like the specs
>of the machine and a vmstat trace of the situation?
The machine is a 550MHz Pentium III with one CPU in a
dual CPU motherboard. It has an Intel 440BX chip set,
512MB of PC-100 SDRAM, a 27GB 5400 RPM IDE hard disk,
100mbps tulip ethernet card, logitech bus mouse, and some
variety of ATI mach64 AGP video card.
Here is the output of vmstat right now, while the problem
is apparently occurring:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 3796 20944 423860 0 0 1 22 250 76 4 27 69
Anyhow, I hope this helps. Thanks for your input into
the situation.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:16 EST