From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@digeo.com>, Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm mailing list <linux-mm@kvack.org>
Subject: Re: ZONE_NORMAL exhaustion (dcache slab)
Date: Mon, 21 Oct 2002 17:31:33 -0700 [thread overview]
Message-ID: <326730000.1035246693@flay> (raw)
In-Reply-To: <3DB4855F.D5DA002E@digeo.com>
>> On Mon, 21 Oct 2002, Martin J. Bligh wrote:
>>
>> > > Blockdevices only use ZONE_NORMAL for their pagecache. That cat will
>> > > selectively put pressure on the normal zone (and DMA zone, of course).
>> >
>> > Ah, I recall that now. That's fundamentally screwed.
>>
>> It's not too bad since the data can be reclaimed easily.
>>
>> The problem in your case is that the dentry and inode cache
>> didn't get reclaimed. Maybe there is a leak so they can't get
>> reclaimed at all or maybe they just don't get reclaimed fast
>> enough.
OK, well "find / | xargs ls -l" results in:
dentry_cache 1125216 1125216 160 46884 46884 1 : 248 124
repeating it gives
dentry_cache 969475 1140960 160 47538 47540 1 : 248 124
Which is only a third of what I eventually ended up with over the weekend,
so presumably that means you're correct and there is a leak.
Hmmm .... but why did it shrink ... I didn't expect mem pressure just
doing a find ....
MemTotal: 16077728 kB
MemFree: 15070304 kB
MemShared: 0 kB
Buffers: 92400 kB
Cached: 266052 kB
SwapCached: 0 kB
Active: 351896 kB
Inactive: 9080 kB
HighTotal: 15335424 kB
HighFree: 15066160 kB
LowTotal: 742304 kB
LowFree: 4144 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 32624 kB
Writeback: 0 kB
Mapped: 4956 kB
Slab: 630216 kB
Reserved: 570464 kB
Committed_AS: 6476 kB
PageTables: 236 kB
ReverseMaps: 3562
Pretty much all in slab ...
ext2_inode_cache 921200 938547 416 104283 104283 1 : 120 60
dentry_cache 1068133 1131096 160 47129 47129 1 : 248 124
So it looks as though it's actually ext2_inode cache that's first against the wall.
For comparison, over the weekend I ended up with:
ext2_inode_cache 554556 554598 416 61622 61622 1 : 120 60
dentry_cache 2791320 2791320 160 116305 116305 1 : 248 124
did a cat of /dev/sda2 > /dev/null ..... after that:
larry:~# egrep '(dentry|inode)' /proc/slabinfo
isofs_inode_cache 0 0 320 0 0 1 : 120 60
ext2_inode_cache 667345 809181 416 89909 89909 1 : 120 60
shmem_inode_cache 3 9 416 1 1 1 : 120 60
sock_inode_cache 16 22 352 2 2 1 : 120 60
proc_inode_cache 12 12 320 1 1 1 : 120 60
inode_cache 385 396 320 33 33 1 : 120 60
dentry_cache 1068289 1131096 160 47129 47129 1 : 248 124
larry:~# cat /proc/meminfo
MemTotal: 16077728 kB
MemFree: 15068684 kB
MemShared: 0 kB
Buffers: 165552 kB
Cached: 266052 kB
SwapCached: 0 kB
Active: 266620 kB
Inactive: 167524 kB
HighTotal: 15335424 kB
HighFree: 15066160 kB
LowTotal: 742304 kB
LowFree: 2524 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 8 kB
Writeback: 0 kB
Mapped: 4956 kB
Slab: 558684 kB
Reserved: 570464 kB
Committed_AS: 6476 kB
PageTables: 236 kB
ReverseMaps: 3563
So it doesn't seem to shrink under mem pressure, but I can't reproduce
the OOM at the moment either ;-(
M.
WARNING: multiple messages have this Message-ID (diff)
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@digeo.com>, Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm mailing list <linux-mm@kvack.org>
Subject: Re: ZONE_NORMAL exhaustion (dcache slab)
Date: Mon, 21 Oct 2002 17:31:33 -0700 [thread overview]
Message-ID: <326730000.1035246693@flay> (raw)
In-Reply-To: <3DB4855F.D5DA002E@digeo.com>
>> On Mon, 21 Oct 2002, Martin J. Bligh wrote:
>>
>> > > Blockdevices only use ZONE_NORMAL for their pagecache. That cat will
>> > > selectively put pressure on the normal zone (and DMA zone, of course).
>> >
>> > Ah, I recall that now. That's fundamentally screwed.
>>
>> It's not too bad since the data can be reclaimed easily.
>>
>> The problem in your case is that the dentry and inode cache
>> didn't get reclaimed. Maybe there is a leak so they can't get
>> reclaimed at all or maybe they just don't get reclaimed fast
>> enough.
OK, well "find / | xargs ls -l" results in:
dentry_cache 1125216 1125216 160 46884 46884 1 : 248 124
repeating it gives
dentry_cache 969475 1140960 160 47538 47540 1 : 248 124
Which is only a third of what I eventually ended up with over the weekend,
so presumably that means you're correct and there is a leak.
Hmmm .... but why did it shrink ... I didn't expect mem pressure just
doing a find ....
MemTotal: 16077728 kB
MemFree: 15070304 kB
MemShared: 0 kB
Buffers: 92400 kB
Cached: 266052 kB
SwapCached: 0 kB
Active: 351896 kB
Inactive: 9080 kB
HighTotal: 15335424 kB
HighFree: 15066160 kB
LowTotal: 742304 kB
LowFree: 4144 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 32624 kB
Writeback: 0 kB
Mapped: 4956 kB
Slab: 630216 kB
Reserved: 570464 kB
Committed_AS: 6476 kB
PageTables: 236 kB
ReverseMaps: 3562
Pretty much all in slab ...
ext2_inode_cache 921200 938547 416 104283 104283 1 : 120 60
dentry_cache 1068133 1131096 160 47129 47129 1 : 248 124
So it looks as though it's actually ext2_inode cache that's first against the wall.
For comparison, over the weekend I ended up with:
ext2_inode_cache 554556 554598 416 61622 61622 1 : 120 60
dentry_cache 2791320 2791320 160 116305 116305 1 : 248 124
did a cat of /dev/sda2 > /dev/null ..... after that:
larry:~# egrep '(dentry|inode)' /proc/slabinfo
isofs_inode_cache 0 0 320 0 0 1 : 120 60
ext2_inode_cache 667345 809181 416 89909 89909 1 : 120 60
shmem_inode_cache 3 9 416 1 1 1 : 120 60
sock_inode_cache 16 22 352 2 2 1 : 120 60
proc_inode_cache 12 12 320 1 1 1 : 120 60
inode_cache 385 396 320 33 33 1 : 120 60
dentry_cache 1068289 1131096 160 47129 47129 1 : 248 124
larry:~# cat /proc/meminfo
MemTotal: 16077728 kB
MemFree: 15068684 kB
MemShared: 0 kB
Buffers: 165552 kB
Cached: 266052 kB
SwapCached: 0 kB
Active: 266620 kB
Inactive: 167524 kB
HighTotal: 15335424 kB
HighFree: 15066160 kB
LowTotal: 742304 kB
LowFree: 2524 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 8 kB
Writeback: 0 kB
Mapped: 4956 kB
Slab: 558684 kB
Reserved: 570464 kB
Committed_AS: 6476 kB
PageTables: 236 kB
ReverseMaps: 3563
So it doesn't seem to shrink under mem pressure, but I can't reproduce
the OOM at the moment either ;-(
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-10-22 0:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-21 20:40 ZONE_NORMAL exhaustion (dcache slab) Martin J. Bligh
2002-10-21 20:40 ` Martin J. Bligh
2002-10-21 21:13 ` Andrew Morton
2002-10-21 21:13 ` Andrew Morton
2002-10-21 21:16 ` Martin J. Bligh
2002-10-21 21:16 ` Martin J. Bligh
2002-10-21 21:33 ` Andrew Morton
2002-10-21 21:33 ` Andrew Morton
2002-10-21 21:33 ` Martin J. Bligh
2002-10-21 21:33 ` Martin J. Bligh
2002-10-21 21:49 ` Andrew Morton
2002-10-21 21:49 ` Andrew Morton
2002-10-21 22:30 ` Rik van Riel
2002-10-21 22:30 ` Rik van Riel
2002-10-21 22:53 ` Andrew Morton
2002-10-21 22:53 ` Andrew Morton
2002-10-22 0:31 ` Martin J. Bligh [this message]
2002-10-22 0:31 ` Martin J. Bligh
2002-10-22 3:39 ` Andrew Morton
2002-10-22 3:39 ` Andrew Morton
2002-10-22 3:53 ` Martin J. Bligh
2002-10-22 3:53 ` Martin J. Bligh
2002-10-22 4:20 ` Andrew Morton
2002-10-22 4:20 ` Andrew Morton
2002-10-22 5:49 ` Martin J. Bligh
2002-10-22 5:49 ` Martin J. Bligh
2002-10-22 6:21 ` Andrew Morton
2002-10-22 6:21 ` Andrew Morton
2002-10-22 16:13 ` Martin J. Bligh
2002-10-22 16:13 ` Martin J. Bligh
2002-10-24 11:35 ` Ed Tomlinson
2002-10-24 11:35 ` Ed Tomlinson
2002-10-24 14:28 ` Martin J. Bligh
2002-10-24 14:28 ` Martin J. Bligh
2002-10-22 16:33 ` Rik van Riel
2002-10-22 16:33 ` Rik van Riel
2002-10-22 16:54 ` ARP address resolving in kernel Steffen Persvold
2002-10-22 17:05 ` ZONE_NORMAL exhaustion (dcache slab) Andrew Morton
2002-10-22 17:05 ` Andrew Morton
2002-10-22 16:21 ` Dipankar Sarma
2002-10-22 16:21 ` Dipankar Sarma
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=326730000.1035246693@flay \
--to=mbligh@aracnet.com \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.