Re: Linux BUG: Memory Leak

[Disconnect <lkml@sigkill.net>]

[-- Attachment #1: Type: text/plain, Size: 4486 bytes --]

For starters, read (and apply!) everyone else's comments re politeness,
proper information to include, etc.

But to add some info in a "Me too":

System has 1G lowmem (the AA vm patches) and showed almost the same
symptoms last night after 1wk of uptime.  Its now been up for about 14
hours with several large processes, agp, etc all going and is - yet
again - running out of memory. (After booting and logging in, 130 megs
was used.. and that was it.)

Kernel: 2.4.20 + patches (see list below)
Memory: PC133 @ 133 - 1024M lowmem, 0M highmem, 2048M swap
Disk: AIC7xxx + LVM1 (raid0)
CPU: Tbird 1.2G non-overclocked
Added modules: lm-sensors, alsa, gatos radeon hardware-gl for X 4.2.0 (X
ver 4.2.1)
Config: Attached

I showed up last night to find it was 900 megs into swap and (relatively
slowly) climbing, but nothing in ps showed a particularly large memory
usage (largest was X, which was - AFAIU - likely to be a mix of "X
leaks" and agp/vidram buffers.. and it was 200M total).  Killed off X
and the other largish apps (apache at 30M, etc..) such that ps showed
well under 300 megs of total VM accounted for.  But free still showed
950 megs of ram and 100 megs of swap in use.  /proc/meminfo showed some
of it (300 megs or so) as buffers, only 16M in cache.

Its been rebooted to the same workload and the same kernel, and happened
again.  That info is attached below.

Basically the patches come from the debian kernel-patch-ck package:

O(1) and batch scheduler (ck)
Author: Ingo Molnar
URL: http://people.redhat.com/mingo/O(1)-scheduler/

Fix for a locking bug in wait_on_page, wait_on_buffer, get_request_wait
(ck)
See the URL below for information on what this patch fixes.
Author: Andrea Arcangeli
URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=103707362523414&w=2
                                                                                Preemptible kernel (ck)
This patch must be enabled via the kernel configuration.
Author: Robert M. Love
URL: http://www.tech9.net/rml/linux/

Low-latency (ck)
This patch must be enabled via the kernel configuration. The "control
low latency with sysctl" configuration option is not needed and will
only disable low latency unless you manually enable it after bootup
(using "echo 1 > /proc/sys/kernel/lowlatency").
Author: Andrew Morton
URL: http://www.zip.com.au/~akpm/linux/schedlat.html

Andrea Arcangeli's VM patches (aa)
Recommended by Con Kolivas for SMP machines.
Author: Andrea Arcangeli
URL: http://www.kernel.org/pub/linux/kernel/people/andrea/

Desktop tuning (tune)
Minor changes to magic numbers benchmarked to improve desktop
responsiveness, and lower disk latency more at the expense of a small
amount of disk throughput.

This patch depends on the (aa) patch, and cannot be used with the (rmap)
patch.

1000Hz timer with autoregulated timeslice duration (vartimeslice)
This patch will adjust the time a process can run for according to the
stress the system is under. If there are many running processes or any
writing to disk the timeslice duration will be decreased. It is
decreased proportionately less in SMP machines. You can see the current
value for timeslice_multiplier by doing 'cat /proc/stat'.

Vairable HZ (varhz)
This patch allows you to configure the frequency the system timer
interrupt pops. Higher tick values provide improved granularity of
timers, improved select() and poll() performance, and lower scheduling
latency. Higher values, however, increase interrupt overhead and will
allow jiffie wraparound sooner.
The default value, which was the value for all of eternity, is 100. If
you are looking to provide better timer granularity or increased desktop
performance, try 500 or 1000. If unsure, go with the default of 100.

Disk read latency update (read_latency)
See the URL below for more information.
URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=101355715821610&w=2

Evidently there is a website about this patcheset:
http://kernel.kolivas.net/

On Wed, 2003-03-12 at 01:49, M. Soltysiak wrote:
> I sent this here because i don't know which author screwed up.
> 
> Basically, it's a massive kernel memory leak or a VM problem.
> 
> System specs:
> 1 GBytes RAM
> duel CPU system; 1 Ghz each.
> IDE disk system, 133 Mhz bus speed, DMA.
> USB mouse.
> PS/2 Keyboard.
> Creative Labs emu10k1-based sound card.  (LIVE!)
> Asus Motherboard.
> 
> Problem:
> 
> When I boot the system, run X11 with KDE--totalling 100 M at most--things 
> are fine.
-- 
Disconnect <lkml@sigkill.net>

[-- Attachment #2: Config.gz --]
[-- Type: application/x-gzip, Size: 6731 bytes --]

[-- Attachment #3: meminfo.gz --]
[-- Type: application/x-gzip, Size: 260 bytes --]

[-- Attachment #4: ps-aux.gz --]
[-- Type: application/x-gzip, Size: 2080 bytes --]

[-- Attachment #5: slabinfo.gz --]
[-- Type: application/x-gzip, Size: 979 bytes --]