From: Andrew Morton <akpm@osdl.org>
To: Chris Wright <chrisw@osdl.org>
Cc: linux-kernel@vger.kernel.org, Nick Piggin <piggin@cyberone.com.au>
Subject: Re: kswapd in tight loop 2.6.9-rc3-bk-recent
Date: Thu, 7 Oct 2004 16:40:44 -0700 [thread overview]
Message-ID: <20041007164044.23bac609.akpm@osdl.org> (raw)
In-Reply-To: <20041007142019.D2441@build.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> wrote:
>
> Is this known? Just came back from lunch, so I've no clue what kicked it
> off. Profile below. (2.6.9-rc3-bk from yesterday, pending updates don't
> appear to touch vmscan or mm/ in general).
>
> CPU: AMD64 processors, speed 1994.35 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
> unit mask
> of 0x00 (No unit mask) count 100000
> samples % symbol name
> 2410135 53.4092 balance_pgdat
> 1328186 29.4329 shrink_zone
> 555121 12.3016 shrink_slab
> 84942 1.8823 __read_page_state
Oh fanfuckingtastic. Something in there is failing to reach its
termination condition. The code has become a trainwreck, so heaven knows
what it was.
For starters, let's actually use that local variable for something.
We haven't been incrementing local variable total_scanned since the
scan_control stuff went in.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/mm/vmscan.c | 1 +
1 files changed, 1 insertion(+)
diff -puN mm/vmscan.c~vmscan-total_scanned-fix mm/vmscan.c
--- 25/mm/vmscan.c~vmscan-total_scanned-fix Thu Oct 7 16:31:55 2004
+++ 25-akpm/mm/vmscan.c Thu Oct 7 16:31:55 2004
@@ -1054,6 +1054,7 @@ scan:
shrink_slab(sc.nr_scanned, GFP_KERNEL, lru_pages);
sc.nr_reclaimed += reclaim_state->reclaimed_slab;
total_reclaimed += sc.nr_reclaimed;
+ total_scanned += sc.nr_scanned;
if (zone->all_unreclaimable)
continue;
if (zone->pages_scanned > zone->present_pages * 2)
_
This probably won't fix it.
It looks like the code will lock up if all zones are out of unreclaimable
memory, but you won't be hitting that.
I also wonder if it'll lock up if just the first zone has ->all_unreclaimable.
I think a good starting point here will be to revert the most recent
change.
next prev parent reply other threads:[~2004-10-07 23:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 21:20 kswapd in tight loop 2.6.9-rc3-bk-recent Chris Wright
2004-10-07 21:39 ` Dave Jones
2004-10-07 21:49 ` Chris Wright
2004-10-07 23:40 ` Andrew Morton [this message]
2004-10-08 0:34 ` Nick Piggin
2004-10-08 0:37 ` Andrew Morton
2004-10-08 0:51 ` Chris Wright
2004-10-08 1:40 ` Andrew Morton
2004-10-08 0:42 ` Andrew Morton
2004-10-08 1:41 ` Chris Wright
2004-10-08 1:51 ` Chris Wright
2004-10-08 1:53 ` Andrew Morton
2004-10-08 2:46 ` Nick Piggin
2004-10-08 3:01 ` Andrew Morton
2004-10-08 3:13 ` Nick Piggin
2004-10-08 3:30 ` Andrew Morton
2004-10-08 3:54 ` Nick Piggin
2004-10-08 4:48 ` Nick Piggin
2004-10-08 4:57 ` Andrew Morton
2004-10-08 5:21 ` Chris Wright
2004-10-08 5:27 ` Chris Wright
2004-10-08 10:10 ` Nick Piggin
2004-10-08 3:15 ` Nick Piggin
2004-10-08 3:05 ` Chris Wright
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=20041007164044.23bac609.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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.