Kernel 2.4.17 gets really slow when handling large files

Kernel 2.4.17 gets really slow when handling large files

[Christiaan Kok]

Dear people,

I have a problem with kernel 2.4.17 and as far as I have testen all the 2.4.X
kernels before it. When handling large files, like moving or viewing movies
(700 Mb) (with mplayer) my system suddenly slows down a lot. This can only be
repaired by a reboot. hdparm -Tt /dev/hdX values drop from around 25 MB/s to
around 8 MB/s but DMA is still on (at least that is what hdaprm reports). In
is a such a state it is imposible to burn cds for instance but networkspeed is
unharmed.

My system is a AMD Athlon 650 on a Aopen AK74 (VIA chipset )/
640Mb memory/NVidia TNT2 with X4 driver from NVidia/2 network cards (vanilla)/
SoundBlaster 128 with ALSA drivers/128MB swap.

I tested with 2.4.17/2.4.10/2.4.10-ac4/2.4.6 and they all have this problem.  

Is this a well-known problem for 2.4.X kernels? Is there a work-around 
available, so I can happily watch movies again?

with best regards,

Christiaan Kok

Re: Kernel 2.4.17 gets really slow when handling large files

[Alan Cox]

> repaired by a reboot. hdparm -Tt /dev/hdX values drop from around 25 MB/s to
> around 8 MB/s but DMA is still on (at least that is what hdaprm reports). In
> is a such a state it is imposible to burn cds for instance but networkspeed is
> unharmed.

Is anything else logged like disk timeouts before the slow down ?

Re: Kernel 2.4.17 gets really slow when handling large files

[brian]

On Fri, Jan 11, 2002 at 11:04:59AM +0100, Christiaan Kok wrote:
> Dear people,
> 
> I have a problem with kernel 2.4.17 and as far as I have testen all the 2.4.X
> kernels before it. When handling large files, like moving or viewing movies
> (700 Mb) (with mplayer) my system suddenly slows down a lot. This can only be
> repaired by a reboot. hdparm -Tt /dev/hdX values drop from around 25 MB/s to
> around 8 MB/s but DMA is still on (at least that is what hdaprm reports). In
> is a such a state it is imposible to burn cds for instance but networkspeed is
> unharmed.

How slow?  Does it always happen when playing large files with mplayer
or only some of the time?

I've run into a similar sounding problem.

Running mplayer, sometimes, perhaps 1 to 50 runs, the system becomes
nearly unresponsive.  I can switch virtual desktops in X, via WM,
promptly.  Through redraws of the switched-to desktop are slow.

xmms playing music continues to play fine.

rxvt's have about a 4 second response time.

Generally, I can manage rebooting the laptop.

Originally I blamed low-latency patches, and have switch back to
2.4.17 with preempt-patch.

-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2002 By Brian Litzinger, All Rights Reserved

Re: Kernel 2.4.17 gets really slow when handling large files

[Timothy Covell]

On Friday 11 January 2002 15:56, brian@worldcontrol.com wrote:
> On Fri, Jan 11, 2002 at 11:04:59AM +0100, Christiaan Kok wrote:
> > Dear people,
> >
> > I have a problem with kernel 2.4.17 and as far as I have testen all the
> > 2.4.X kernels before it. When handling large files, like moving or
> > viewing movies (700 Mb) (with mplayer) my system suddenly slows down a
> > lot. This can only be repaired by a reboot. hdparm -Tt /dev/hdX values
> > drop from around 25 MB/s to around 8 MB/s but DMA is still on (at least
> > that is what hdaprm reports). In is a such a state it is imposible to
> > burn cds for instance but networkspeed is unharmed.
>
> How slow?  Does it always happen when playing large files with mplayer
> or only some of the time?
>
> I've run into a similar sounding problem.
>
> Running mplayer, sometimes, perhaps 1 to 50 runs, the system becomes
> nearly unresponsive.  I can switch virtual desktops in X, via WM,
> promptly.  Through redraws of the switched-to desktop are slow.
>
> xmms playing music continues to play fine.
>
> rxvt's have about a 4 second response time.
>
> Generally, I can manage rebooting the laptop.
>
> Originally I blamed low-latency patches, and have switch back to
> 2.4.17 with preempt-patch.

I'm assuming that you have checked to make sure that your system
hasn't run out of memory and is swapping heavily.   If mplayer had
a memory leak this could be the expected behaviour.  [when in X,
I usually keep xosview or some similar meter open so that I can
see cpu, memory, and swap usage.]

-- 
timothy.covell@ashavan.org.