lkml.org 
[lkml]   [2002]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectMemory thrashing in the Kernel.
Date
Hi,
I have developed a Kernel module with a sockets Address Family that
interfaces to our hardware. We are shifting large amounts of data through
the card at high speed. To get up-and-running quickly I just kmalloc'd and
kfree'd memory for the buffers and control structures as required. When I
start a soak test on the 2.4.17 Kernel, the memory stats hover at the
following

total used free shared buffers cached
Mem: 189932 184892 5040 0 2392 161564
-/+ buffers/cache: 20936 168996
Swap: 385552 0 385552

Whereas on the 2.2.19 Kernel I get

total used free shared buffers cached
Mem: 192604 98512 94092 33944 66132 8872
-/+ buffers/cache: 23508 169096
Swap: 393552 0 393552

I don't seem to run out, so I think I must be kfree'ing all the memory.
When I stop the test, the not much of the memory seems to make it back to
the free pool.

Sometimes, under very heavy load conditions, a call to kmalloc fails (no
memory) on the 2.4.17 system. I guess that the memory recycling cannot keep
up?

Here are my questions:

1) Was there a big change in memory handling between the 2.2.x and 2.4.x
kernels? The 2.2.x memory handling seems to be more responsive than the
2.4.x

2) Is there a config change I can make speed up the recycling?

3) I'd much prefer to stop thrashing the memory at all. So, does anyone
know of some buffer pool handling routines that I could use?


Thanks

Kevin

-----Original Message-----
From: Mark Lord [mailto:mlord@pobox.com]
Sent: 31 July 2002 13:19
To: Mukesh Rajan
Cc: linux-kernel@vger.kernel.org
Subject: Re: IDE, putting HD to sleep causes "lost interrupt"


Well, the answer is very simple, then: DON'T DO THAT.

When an ATA (IDE) drive is put to sleep (-Y),
it *requires* a reset to revive it for any future commands.

The IDE driver doesn't know about the -Y, so it just attempts
I/O a few times before digging out the BIG hammer and doing a reset.

All is well.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com


Mukesh Rajan wrote:
>
> hi,
>
> things work perfectly fine on my desktop. but on my laptop (toshiba
> satellite) if i try,
>
> %hdparm -Y /dev/hda <--- put to sleep followed by
> %hdparm -C /dev/hda <--- query status
>
> gives me
>
> hda: lost interrupt
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x50 { DriveReady SeekComplete }
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x50 { DriveReady SeekComplete }
> hda: lost interrupt
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x50 { DriveReady SeekComplete }
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x50 { DriveReady SeekComplete }
> hda: DMA disabled
> ide0: reset: success
>
> if i try the above from X, the machine freezes and i need to do hard
> reboot.
>
> the boot message regarding ide are as follows
>
> boot messages
> -------------
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 20
> PCI: No IRQ known for interrupt pin A of device 00:04.0. Please try using
> pci=biosirq.
> ALI15X3: chipset revision 195
> ALI15X3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xeff0-0xeff7, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xeff8-0xefff, BIOS settings: hdc:DMA, hdd:pio
> hda: TOSHIBA MK2018GAP, ATA DISK drive
>
> the closest i think i got to on google is the following but there are no
> answers
>
> http://mail.nl.linux.org/kernelnewbies/2001-01/msg00064.html
>
> please help.
>
> - mukesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.037 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site