linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@digeo.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
	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 20:53:59 -0700	[thread overview]
Message-ID: <2622146086.1035233637@[10.10.2.3]> (raw)
In-Reply-To: <3DB4C87E.7CF128F3@digeo.com>

> I cannot make it happen here, either.  2.5.43-mm2 or current devel
> stuff.  Heisenbug; maybe something broke dcache-rcu?  Or the math
> overflow (unlikely).

Dipankar is going to give me some debug code once he's slept for
a while ... that should help see if dcache-rcu went wacko.
 
>> So it looks as though it's actually ext2_inode cache that's first against the wall.
> 
> Well that's to be expected.  Each ext2 directory inode has highmem
> pagecache attached to it, which pins the inode.  There's no highmem
> eviction pressure so your normal zone gets stuffed full of inodes.
> 
> There's a fix for this in Andrea's tree, although that's perhaps a
> bit heavy on inode_lock for 2.5 purposes.  It's a matter of running
> invalidate_inode_pages() against the inodes as they come off the
> unused_list.  I haven't got around to it yet.

Thanks; no urgent problem (though we did seem to have a customer hitting
a very similar situation very easily in 2.4 ... we'll see if Andrea's
fixes that, then I'll try to reproduce their problem on current 2.5).
 
>> 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
> 
> OK, so there's reasonable dentry shrinkage there, and the inodes
> for regular files whch have no attached pagecache were reaped.
> But all the directory inodes are sitting there pinned.

OK, this all makes a lot of sense ... apart from one thing:
from looking at meminfo:

HighTotal:    15335424 kB
HighFree:     15066160 kB

Even if every highmem page is pagecache, that's only 67316 pages by
my reckoning (is pagecache broken out seperately in meminfo? both
Buffers and Cached seem to large). If I only have 67316 page of 
pagecache, how can I have 667345 inodes with attatched pagecache pages?
Or am I just missing something obvious and fundamental? 
--
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  3:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-21 20:40 Martin J. Bligh
2002-10-21 21:13 ` Andrew Morton
2002-10-21 21:16   ` Martin J. Bligh
2002-10-21 21:33     ` Andrew Morton
2002-10-21 21:33       ` Martin J. Bligh
2002-10-21 21:49         ` Andrew Morton
2002-10-21 22:30         ` Rik van Riel
2002-10-21 22:53           ` Andrew Morton
2002-10-22  0:31             ` Martin J. Bligh
2002-10-22  3:39               ` Andrew Morton
2002-10-22  3:53                 ` Martin J. Bligh [this message]
2002-10-22  4:20                   ` Andrew Morton
2002-10-22  5:49                     ` Martin J. Bligh
2002-10-22  6:21                       ` Andrew Morton
2002-10-22 16:13                         ` Martin J. Bligh
2002-10-24 11:35                   ` Ed Tomlinson
2002-10-24 14:28                     ` Martin J. Bligh
2002-10-22 16:33             ` Rik van Riel
2002-10-22 17:05               ` Andrew Morton
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='2622146086.1035233637@[10.10.2.3]' \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox