From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Grzegorz Kulewski <kangur@polcom.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: Memory and rsync problem with vanilla 2.6.7
Date: Sun, 20 Jun 2004 13:47:52 +1000 [thread overview]
Message-ID: <40D508E8.2050407@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.58.0406191040170.6178@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]
Linus Torvalds wrote:
>
> On Sat, 19 Jun 2004, Grzegorz Kulewski wrote:
>
>>Is this bug or feature? Is there some wreid memmory leak? Where is my RAM?
>
>
> Your memory is apparently in dentry and inode memory:
>
> ext3_inode_cache 62553 62553 4096 (244MB)
> dentry_cache 48768 48768 4096 (190MB)
>
> and it really looks like you have enabled CONFIG_DEBUG_PAGEALLOC, which
> just eats memory like mad (a dentry is normally ~200 bytes, but then when
> it is rounded up to page-size, it takes 20 times the memory).
>
> So don't enable DEBUG_PAGEALLOC unless you really want to debug some
> strange problem.
>
This could be it. But can you check whether your previous well-behaving
kernel also has CONFIG_DEBUG_PAGEALLOC on? If so, then it is possible
that VM behaviour has regressed.
Of course, DEBUG_PAGEALLOC is the wrong target to attempt to tune for:
without it, those above two items would take up a combined 40 megs.
> That said, there might be a memory balancing problem too, and
> DEBUG_PAGEALLOC just makes it more obvious. Nick Piggin reports that an
> "obvious fix" by Andrew potentially causes problems, and if you're a BK
> user, you could try just backing out this cset:
>
> ChangeSet@1.1722.88.2, 2004-06-03 07:58:03-07:00, akpm@osdl.org
> [PATCH] shrink_all_memory() fixes
>
> ....
>
> (check with "bk changes" what the revision is in your tree, and do a
>
> bk cset -xX.XXX.XX.X
>
> to try reverting it. Quite possibly that fix makes the VM much less likely
> to throw out the VM caches, which would make the debug problem much
> worse).
>
Well it doesn't seem to have caused too much trouble as yet... But it
is the obvious candidate if your problems continue. If you are not a
bk user, the attached patch will also revert that change.
[-- Attachment #2: vm-revert-fix.patch --]
[-- Type: text/x-patch, Size: 998 bytes --]
linux-2.6-npiggin/mm/vmscan.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff -puN mm/vmscan.c~vm-revert-fix mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-revert-fix 2004-06-12 16:53:02.000000000 +1000
+++ linux-2.6-npiggin/mm/vmscan.c 2004-06-12 16:54:26.000000000 +1000
@@ -813,9 +813,8 @@ shrink_caches(struct zone **zones, int p
struct zone *zone = zones[i];
int max_scan;
- zone->temp_priority = priority;
- if (zone->prev_priority > priority)
- zone->prev_priority = priority;
+ if (zone->free_pages < zone->pages_high)
+ zone->temp_priority = priority;
if (zone->all_unreclaimable && priority != DEF_PRIORITY)
continue; /* Let kswapd poll it */
@@ -996,8 +995,6 @@ scan:
all_zones_ok = 0;
}
zone->temp_priority = priority;
- if (zone->prev_priority > priority)
- zone->prev_priority = priority;
max_scan = (zone->nr_active + zone->nr_inactive)
>> priority;
reclaimed = shrink_zone(zone, max_scan, GFP_KERNEL,
_
next prev parent reply other threads:[~2004-06-20 3:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-26 8:39 2.6.6-rc2-mm2 Andrew Morton
2004-04-26 16:55 ` 2.6.6-rc2-mm2 Zwane Mwaikambo
2004-04-26 17:11 ` 2.6.6-rc2-mm2 raven
2004-04-26 17:37 ` 2.6.6-rc2-bk3 (and earlier?) mount problem (?) Grzegorz Kulewski
2004-04-26 18:08 ` Linus Torvalds
2004-04-26 22:08 ` Grzegorz Kulewski
2004-04-26 22:13 ` Linus Torvalds
2004-04-26 22:38 ` Grzegorz Kulewski
2004-04-26 22:56 ` viro
2004-04-27 0:04 ` Grzegorz Kulewski
2004-04-27 0:23 ` viro
2004-04-27 0:43 ` viro
2004-04-27 1:00 ` Linus Torvalds
2004-04-27 1:07 ` 2.6.6-rc2-bk3 (and earlier?) mount problem (? viro
2004-04-27 9:12 ` Grzegorz Kulewski
2004-04-27 12:51 ` Chris Mason
2004-04-27 13:07 ` Grzegorz Kulewski
2004-04-27 14:05 ` Paul P Komkoff Jr
2004-04-27 18:34 ` viro
2004-04-27 20:04 ` Paul P Komkoff Jr
2004-04-27 20:28 ` viro
2004-04-27 20:39 ` Grzegorz Kulewski
2004-04-27 21:35 ` viro
2004-04-27 21:59 ` Grzegorz Kulewski
2004-04-28 10:19 ` Paul P Komkoff Jr
2004-06-19 16:59 ` Memory and rsync problem with vanilla 2.6.7 Grzegorz Kulewski
2004-06-19 17:50 ` Linus Torvalds
2004-06-20 3:47 ` Nick Piggin [this message]
2004-06-20 14:18 ` Grzegorz Kulewski
2004-06-20 14:41 ` Grzegorz Kulewski
2004-06-20 14:45 ` Nick Piggin
2004-06-20 20:34 ` Grzegorz Kulewski
2004-06-21 16:22 ` Grzegorz Kulewski
2004-06-20 13:24 ` Grzegorz Kulewski
2004-06-20 14:04 ` Sam Ravnborg
2004-06-21 18:36 ` network related(?) kernel panic (2.6.7-bk4) Grzegorz Kulewski
2004-04-26 18:52 ` 2.6.6-rc2-mm2 Frédéric L. W. Meunier
2004-04-26 23:06 ` 2.6.6-rc2-mm2 (compile stats) John Cherry
2004-04-28 9:37 ` 2.6.6-rc2-mm2 William Lee Irwin III
2004-04-29 18:41 ` 2.6.6-rc2-mm2 William Lee Irwin III
2004-04-29 20:45 ` 2.6.6-rc2-mm2 Andrew Morton
2004-04-29 21:18 ` 2.6.6-rc2-mm2 William Lee Irwin III
2004-04-30 0:24 ` 2.6.6-rc2-mm2 William Lee Irwin III
2004-04-30 2:05 ` 2.6.6-rc2-mm2 James Bottomley
2004-04-30 2:24 ` 2.6.6-rc2-mm2 William Lee Irwin III
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=40D508E8.2050407@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=kangur@polcom.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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