In the past month there was a short thread called:
"high load on heavy disk i/o"
http://www.uwsg.indiana.edu/hypermail/linux/kernel/9909.3/0899.html
That thread discussed an I/O related problem that I experience as well. The
intention I have with this mail to the list is to catch the attention of
the developers that handle the parts of the kernel related to the problem.
Since I'm not a kernel developer myself I'm not able to clearly identify
the problem and do not know which specific developer to contact. I will
present it as detailed as I possibly can so that this issue might get some
attention. The original author of the above mentioned thread (Ronald Wahl)
still has not found a solution.
In short: When writing large files to an ext2fs partition my system crawls.
My hardware:
Motherboard: Microstar 6120 dual processor motherboard
Processors: Two Intel Celeron 300A oc'ed to 450MHz
Memory: 128MB SDRAM (non-ECC).
PCI cards: (five cards)
Adaptec 2940UW, Matrox Millenium I (4MB),
Generic Voodoo2, Luxsonor MPEG/AC-3 card,
ASIX 88140 NIC.
ISA cards: Soundblaster 32 PnP
IRQ collisions: none.
IDE devices: none.
SCSI devices: (connected to the Adaptec 2940UW)
Quantum Fireball ST 4.3GB U-SCSI
Pioneer DVD-303 U-SCSI
Yamaha 4260 CDR async SCSI
My software:
Linux distribution: Debian potato (unstable)
Software version info:
Kernel modules 2.3.5
Gnu C 2.95.2
Binutils 2.9.5.0.14
Linux C Library 1.2.so
Dynamic Linker (ld.so) 1.9.11
Procps 2.0.3
Mount 2.9x
Environment:
The kernel versions I've tried recently all exhibit this problem. They are:
2.2.1, 2.2.12, 2.2.13pre7, 2.3.22
I never altered any settings via the /proc interface (bdflush etc..) and
used the stock kernel drivers for everything but the NIC, which is a
problem child that has to use the 0.91h+ version of the tulip driver to be
reasonably stable (thanks Donald).
When I was using kernel 2.2.1 I tried an UP kernel as well but I got the
same results as with a SMP kernel.
I have two filesystems on the disk, one 500 MB FAT32 to boot Windows and
the rest is ext2fs partitions with varying block size (1,2&4K). All ext2fs
partitions are affected by this - not the FAT32 partition. This should rule
out the possibility that there are problems in the SCSI driver, it should
be related to ext2fs. But then, what do I know?
So how do I trigger this strange behaviour?
The easiest way to make the system useless is by writing large files
(>100MB) to disk. Any process that require concurrent disk I/O will be
sloooooow. Small processes like cpu-load monitors aren't affected that much
by this but as soon as something is needed from disk even they hit a brick
wall. Bonnie is a sure way to trigger the problem, try 'bonnie -s 400' on
your system.
My P166 gateway (kernel 2.2.12) is a super-fileserver compared to my dual
machine when executing bonnie and it's using only IDE devices (RAID0
2xIBM14GXP) and 64 MB memory. Sure, a RAID0 strip with two new drives are
faster but the throughput also bogs down the CPU but the system is still
responsive and that's the problem with the dual/SCSI machine which should
have no problems at all handling one 5400 rpm SCSI disk.
An observation I made while transferring a large file from my gateway (in
100Mbit full duplex) was that the first 70-80 MB's were real easy but I
suspect that the filesystem buffers are saturated by then as that's about
the amount of memory left over (out of 128MB) for buffering when I perform
the test. After it passes this point all you can do is wait or abort the
operation.
Another funny thing is that although the machine is totally useless while
the writing takes place, the amount of CPU used is nothing remarkable as
can be seen when watching 'top'. Below is the output from bonnie on my two
systems. Both machines are using kernel 2.2.12pre7 and the ext2fs
partitions the tests are performed on are both using 4K block size. The
first two entries are using the dual machine.
-------Sequential Output-------- ---Sequential Input--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
ext2 200 3072 44.4 2982 3.4 1806 4.5 4700 65.1 4365 5.0 88.0 1.6
fat32 200 2620 40.7 2665 5.6 1633 16.0 4670 68.4 6220 9.7 83.4 13.7
P166 400 1851 98.0 17450 90.8 7495 70.7 1950 98.5 22086 86.8 143.7 4.1
I think '%CPU' is referring to the usage of one CPU which means that only 25% of
the cycles are spent when using putc() on the dual machine but nearly 100%
on the single processor machine. I just wish I could UDMA and not just
"DMA" on the P166 but the IDE driver combined with the motherboard, disks
and possibly cabling won't agree.
As can be observed above there should be no huge difference in cpu cycles left
over between using fat32 and ext2fs but the interactive experience says
otherwise.
Best regards
Mattias
-- Mattias Sandgren - mailto:sagge@acc.umu.se http://www.acc.umu.se/~sagge Computer Science and Engineering Student - University of Umea, Sweden. One of them unix geeks. ( ( ( (( In Stereo Where Available )) ) ) )
- 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/