All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.