From: Ken Brownfield <brownfld@irridia.com>
To: Leigh Orf <orf@mailbag.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.16 memory badness (reproducible)
Date: Sat, 8 Dec 2001 09:56:20 -0600 [thread overview]
Message-ID: <20011208095620.C1179@asooo.flowerfire.com> (raw)
In-Reply-To: <200112081539.fB8FdFj03048@orp.orf.cx>
In-Reply-To: <200112081539.fB8FdFj03048@orp.orf.cx>; from orf@mailbag.com on Sat, Dec 08, 2001 at 10:39:14AM -0500
This parallels what I'm seeing -- perhaps inode/dentry cache bloat is
causing the memory issue (which mimics if not _is_ a memory leak) _and_
my kswapd thrashing? It fits both the situation you report and what I'm
seeing with I/O across a large number of files (inodes) -- updatedb,
smb, NFS, etc.
I think Andrea was on to this issue, so I'm hoping his work will help.
Have you tried an -aa kernel or an aa patch onto a 2.4.17-pre4 to see
how the kernel's behavior changes?
--
Ken.
brownfld@irridia.com
On Sat, Dec 08, 2001 at 10:39:14AM -0500, Leigh Orf wrote:
|
| I've been having confounding out-of-memory problems with 2.4.16 on my
| 1.4MHz Athlon with 1 GB of memory (2 GB of swap). I just caught it in
| the act and I think it relates to some of the weirdness others have been
| reporting.
|
| I'm running RedHat 7.2. After bootup, it runs a program called updatedb
| (slocate -u) which does a lot of file i/o as it indexes all the files on
| my hard drives. Following this action, my machine is in a state which
| make many applications give "cannot allocate memory" errors. It seems
| the kernel is not freeing up buffered or cached memory, and even more
| troubling is the fact that it isn't using any of my swap space.
|
| Here is the state of the machine after updatedb runs:
|
| home[1006]:/home/orf% free
| total used free shared buffers cached
| Mem: 1029820 1021252 8568 0 471036 90664
| -/+ buffers/cache: 459552 570268
| Swap: 2064344 0 2064344
|
| home[1003]:/home/orf% cat /proc/meminfo
| total: used: free: shared: buffers: cached:
| Mem: 1054535680 1045901312 8634368 0 480497664 93954048
| Swap: 2113888256 0 2113888256
| MemTotal: 1029820 kB
| MemFree: 8432 kB
| MemShared: 0 kB
| Buffers: 469236 kB
| Cached: 91752 kB
| SwapCached: 0 kB
| Active: 383812 kB
| Inactive: 229016 kB
| HighTotal: 130992 kB
| HighFree: 2044 kB
| LowTotal: 898828 kB
| LowFree: 6388 kB
| SwapTotal: 2064344 kB
| SwapFree: 2064344 kB
|
| home[1005]:/home/orf% cat /proc/slabinfo
| slabinfo - version: 1.1
| kmem_cache 65 68 112 2 2 1
| ip_conntrack 9 50 384 4 5 1
| nfs_write_data 0 0 384 0 0 1
| nfs_read_data 0 0 384 0 0 1
| nfs_page 0 0 128 0 0 1
| ip_fib_hash 10 112 32 1 1 1
| urb_priv 0 0 64 0 0 1
| clip_arp_cache 0 0 128 0 0 1
| ip_mrt_cache 0 0 128 0 0 1
| tcp_tw_bucket 0 0 128 0 0 1
| tcp_bind_bucket 8 112 32 1 1 1
| tcp_open_request 0 0 128 0 0 1
| inet_peer_cache 4 59 64 1 1 1
| ip_dst_cache 27 40 192 2 2 1
| arp_cache 3 30 128 1 1 1
| blkdev_requests 640 660 128 22 22 1
| journal_head 0 0 48 0 0 1
| revoke_table 0 0 12 0 0 1
| revoke_record 0 0 32 0 0 1
| dnotify cache 0 0 20 0 0 1
| file lock cache 2 42 92 1 1 1
| fasync cache 2 202 16 1 1 1
| uid_cache 5 112 32 1 1 1
| skbuff_head_cache 327 340 192 17 17 1
| sock 188 198 1280 66 66 1
| sigqueue 2 29 132 1 1 1
| cdev_cache 2313 2360 64 40 40 1
| bdev_cache 8 59 64 1 1 1
| mnt_cache 19 59 64 1 1 1
| inode_cache 439584 439586 512 62798 62798 1
| dentry_cache 454136 454200 128 15140 15140 1
| dquot 0 0 128 0 0 1
| filp 1471 1500 128 50 50 1
| names_cache 0 2 4096 0 2 1
| buffer_head 144413 173280 128 5776 5776 1
| mm_struct 57 80 192 4 4 1
| vm_area_struct 2325 2760 128 92 92 1
| fs_cache 56 118 64 2 2 1
| files_cache 56 72 448 8 8 1
| signal_act 64 72 1344 24 24 1
| size-131072(DMA) 0 0 131072 0 0 32
| size-131072 0 0 131072 0 0 32
| size-65536(DMA) 0 0 65536 0 0 16
| size-65536 1 1 65536 1 1 16
| size-32768(DMA) 0 0 32768 0 0 8
| size-32768 1 1 32768 1 1 8
| size-16384(DMA) 0 0 16384 0 0 4
| size-16384 1 1 16384 1 1 4
| size-8192(DMA) 0 0 8192 0 0 2
| size-8192 4 4 8192 4 4 2
| size-4096(DMA) 0 0 4096 0 0 1
| size-4096 64 68 4096 64 68 1
| size-2048(DMA) 0 0 2048 0 0 1
| size-2048 52 66 2048 27 33 1
| size-1024(DMA) 0 0 1024 0 0 1
| size-1024 11042 11048 1024 2762 2762 1
| size-512(DMA) 0 0 512 0 0 1
| size-512 12004 12016 512 1501 1502 1
| size-256(DMA) 0 0 256 0 0 1
| size-256 1678 1695 256 113 113 1
| size-128(DMA) 2 30 128 1 1 1
| size-128 29398 29430 128 980 981 1
| size-64(DMA) 0 0 64 0 0 1
| size-64 7954 7965 64 135 135 1
| size-32(DMA) 34 59 64 1 1 1
| size-32 66711 66729 64 1131 1131 1
|
| Now, I try to run a common application:
|
| home[1031]:/home/orf% xmms
| Memory fault
|
| Strace on xmms shows:
|
| home[1008]:/home/orf/memfuck% cat xmms.strace
| [snip]
| modify_ldt(0x1, 0xbffff1fc, 0x10) = -1 ENOMEM (Cannot allocate memory)
| --- SIGSEGV (Segmentation fault) ---
| +++ killed by SIGSEGV +++
|
| Also, from my syslog (I have an ntfs partition):
|
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_insert_run: ntfs_vmalloc(new_size = 0x1000) failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_process_runs: ntfs_insert_run failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_getdir_unsorted(): Read failed. Returning error code -95.
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_insert_run: ntfs_vmalloc(new_size = 0x1000) failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_process_runs: ntfs_insert_run failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_getdir_unsorted(): Read failed. Returning error code -95.
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_insert_run: ntfs_vmalloc(new_size = 0x1000) failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_process_runs: ntfs_insert_run failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_insert_run: ntfs_vmalloc(new_size = 0x1000) failed
| Dec 8 09:55:01 orp kernel: NTFS: ntfs_process_runs: ntfs_insert_run failed
|
| The program nautilus, which is involved with the Gnome windowing stuff,
| also complains it can't allocate memory if I log into the console after
| udpatedb has run (that's what clued me into this problem in the first
| place).
|
| The only way I can find to make the system usable is to run an
| application which aggressively recovers some of this buffered/cached
| memory, and quit it. One easy way to do this:
|
| home[1014]:/home/orf% lmdd opat=1 count=1 bs=900m
|
| After I do this, much free memory is available.
|
| Some applications are able to "reclaim" the buffered/cached memory,
| while others aren't. Netscape doesn't have a problem, for instance,
| running after updatedb runs.
|
| This is a pretty serious problem. Interestingly enough, it does NOT
| occur on my other machine, running same kernel and RH7.2, with 256M
| memory and 512M swap.
|
| Leigh Orf
|
| -
| 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/
next prev parent reply other threads:[~2001-12-08 15:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-08 15:39 2.4.16 memory badness (reproducible) Leigh Orf
2001-12-08 15:56 ` Ken Brownfield [this message]
2001-12-08 18:54 ` Leigh Orf
2001-12-08 19:41 ` Andrew Morton
2001-12-08 20:04 ` Leigh Orf
2001-12-08 21:42 ` Leigh Orf
2001-12-08 22:24 ` Leigh Orf
2001-12-11 19:07 ` Hugh Dickins
2001-12-11 20:04 ` Stephan von Krawczynski
2001-12-11 22:13 ` H. Peter Anvin
2001-12-11 22:59 ` Andrea Arcangeli
2001-12-12 14:51 ` Leigh Orf
2001-12-18 14:27 ` Holger Lubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011208095620.C1179@asooo.flowerfire.com \
--to=brownfld@irridia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=orf@mailbag.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox