I have an ext[23] filesystem (doesn't matter which), on an LVM Volume.
Whenever I do some heavy disk-I/O (like untaring an archive with 13000
files that amount to 5GB), the CPU-state repeatedly goes to 99.9%
system and stays there for a noticeable amount of time (1-2 seconds),
during which the system doesn't respond very well to user action, to put
it mildly.
Whenever this happens, top shows kupdated as one of the most active
processes (sometimes it also claims that top uses 54% of the CPU, but
I guess that is only marginally accurate). bdflush (which according to
google was mentioned in connection to a similar problem some time
ago) doesn't do anything.
The system is an Athlon XP 1800+ on a Gigabyte GA7-VTXE board with
one IDE disk.
Kernel is 2.4.18-pre9, LVM utilities 1.0.1release, is there anything
else that is relevant?
Please CC answers to me.
Yours, Florian.
Heinz Diehl wrote:
> Downgrade to 2.4.18-pre8 and use Michael Cohen's patch from
> "ftp://ftp.kernel.org/pub/linux/kernel/people/mjc/linux-2.4/",
That doesn't help. I tried 2.4.16 with Debian modifications, said
kernel patched to 2.4.18-pre9, stock 2.4.17, stock 2.4.18-pre9 and
2.4.18-pre8-mjc with preempt and lockbreak, and all behave alike.
On a plain ext2-filesystem on a primary partition I get (with -mjc):
During the sync the system is extremly sluggish, and once during my
tests it froze completely (it did still return pings with a normal
speed) so that I had to press reset.
The same operations on a slower computer running 2.2.20 are consideraby
faster:
$ time tar -xzf linux-2.4.17.tar.gz; time sync
real 0m7.716s
user 0m5.430s
sys 0m2.110s
real 0m6.332s
user 0m0.000s
sys 0m0.120s
> Latency in stock 2.4.17/18-pre kernels is well known :\
this looks like more than a latency issue :-(.
Yours, Florian Hars.
Soyy, I just hit the wrong key before pasting in the numbers, so
here they are:
> On a plain ext2-filesystem on a primary partition I get (with -mjc):
# time tar -xzf linux-2.4.17.tar.gz; time sync
real 0m18.818s
user 0m1.890s
sys 0m14.740s
real 0m21.990s
user 0m0.000s
sys 0m11.320s
Yours, Florian Hars.
Florian Hars wrote:
>
> I have an ext[23] filesystem (doesn't matter which), on an LVM Volume.
> Whenever I do some heavy disk-I/O (like untaring an archive with 13000
> files that amount to 5GB), the CPU-state repeatedly goes to 99.9%
> system and stays there for a noticeable amount of time (1-2 seconds),
> during which the system doesn't respond very well to user action, to put
> it mildly.
A kernel profile will presumably point us at the problem.
It's pretty simple. See
http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.3/0773.html
-
Hi Folks: I downloaded the 2.5.4 tar ball and applied a one line
patch by Dave ??? I don't remember his last name. Most of the kernel
compiled just fine until I got to the loader stage. I have tried the
compile a number of times removing newer features I had included from
the 2.5.4 configuration. It continually dies just after the ld
stage. Here's the log:
ld -m elf_i386 -T /usr/src/linux-2.5.4/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o init/do_mounts.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
/usr/src/linux-2.5.4/arch/i386/lib/lib.a /usr/src/linux-2.5.4/lib/lib.a /usr/src/linux-2.5.4/arch/i386/lib/lib.a \
drivers/base/base.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o \
net/network.o \
--end-group \
-o vmlinux
drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit'
drivers/net/net.o(.data+0x174): undefined reference to `local symbols in discarded section .text.exit'
make: *** [vmlinux] Error 1
Once again could someone help the clewless?
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
I wrote:
> Whenever I do some heavy disk-I/O (like untaring an archive with 13000
> files that amount to 5GB), the CPU-state repeatedly goes to 99.9%
> system
Part of the problem could be alleviated by unmasking the interrupts,
but now some part of the IDE system is crying for its master:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: Unknown VIA SouthBridge, contact Vojtech Pavlik <[email protected]>
I use a Gigabyte GA-7VTXE with a VIA KT266A chipset and a Southbridge
called VT8233A, which does not look like one of the "FUTURE_BRIDGES"
that are ifdefed out in the driver (or is it the same as the
{ "vt8233c", PCI_DEVICE_ID_VIA_8233C, 0x00, 0x2f, VIA_UDMA_100 } ?).
Yours, Florian Hars.
On Tue, Feb 12, 2002 at 11:20:05AM +0100, Florian Hars wrote:
> I wrote:
> > Whenever I do some heavy disk-I/O (like untaring an archive with 13000
> > files that amount to 5GB), the CPU-state repeatedly goes to 99.9%
> > system
>
> Part of the problem could be alleviated by unmasking the interrupts,
> but now some part of the IDE system is crying for its master:
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 89
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: Unknown VIA SouthBridge, contact Vojtech Pavlik <[email protected]>
>
> I use a Gigabyte GA-7VTXE with a VIA KT266A chipset and a Southbridge
> called VT8233A, which does not look like one of the "FUTURE_BRIDGES"
> that are ifdefed out in the driver (or is it the same as the
> { "vt8233c", PCI_DEVICE_ID_VIA_8233C, 0x00, 0x2f, VIA_UDMA_100 } ?).
>
> Yours, Florian Hars.
2.5.2 (and later, and maybe some earlier versions as well) have support
for this chipset. You can copy over the via82cxxx.c and ide-timing.h to
your kernel and it should work.
--
Vojtech Pavlik
SuSE Labs
begin Vojtech Pavlik quote:
> On Tue, Feb 12, 2002 at 11:20:05AM +0100, Florian Hars wrote:
> > I use a Gigabyte GA-7VTXE with a VIA KT266A chipset and a Southbridge
> > called VT8233A, which does not look like one of the "FUTURE_BRIDGES"
>
> 2.5.2 (and later, and maybe some earlier versions as well) have support
> for this chipset. You can copy over the via82cxxx.c and ide-timing.h to
> your kernel and it should work.
Not really:
via82cxxx.c: In function `ide_init_via82cxxx':
via82cxxx.c:548: structure has no member named `highmem'
make[4]: *** [via82cxxx.o] Fehler 1
I had to remove the offending line (it isn't there in the 2.4 version
of the file), and of course add the PCI ID of the SouthBridge in
the appropriate places. Now the system boots and hdparm says that
dma is activated. So lets see how well it behaves...
Yours, Florian Hars.
On Tue, Feb 12, 2002 at 02:36:19PM +0100, Florian Hars wrote:
> begin Vojtech Pavlik quote:
> > On Tue, Feb 12, 2002 at 11:20:05AM +0100, Florian Hars wrote:
> > > I use a Gigabyte GA-7VTXE with a VIA KT266A chipset and a Southbridge
> > > called VT8233A, which does not look like one of the "FUTURE_BRIDGES"
> >
> > 2.5.2 (and later, and maybe some earlier versions as well) have support
> > for this chipset. You can copy over the via82cxxx.c and ide-timing.h to
> > your kernel and it should work.
>
> Not really:
>
> via82cxxx.c: In function `ide_init_via82cxxx':
> via82cxxx.c:548: structure has no member named `highmem'
> make[4]: *** [via82cxxx.o] Fehler 1
Yes, it's for 2.5.
> I had to remove the offending line (it isn't there in the 2.4 version
> of the file), and of course add the PCI ID of the SouthBridge in
> the appropriate places. Now the system boots and hdparm says that
> dma is activated. So lets see how well it behaves...
I've sent a patch to Jens Axboe for inclusion into 2.4, so it might be
in 2.4.18. If you find any flaws, please tell me soon enough so I can
stop the inclusion in time ...
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Tue, Feb 12, 2002 at 02:36:19PM +0100, Florian Hars wrote:
> > [Via VT8233A Southbridge]
>
> I've sent a patch to Jens Axboe for inclusion into 2.4, so it might be
> in 2.4.18. If you find any flaws, please tell me soon enough so I can
> stop the inclusion in time ...
I made a naive stress test (untaring a 5GB archive into an ext3 filesystem
on a LVM volume, while running fsx on the same filesystem (don't know if it
is relevant for this problem) and throwing in an occasional hdparm -Tt) and
everything looked good, even mozilla was still responsive.
Thanks for your help.
Yours, Florian.