From: Andrew Morton <akpm@osdl.org>
To: Steven Cole <elenstev@mesatop.com>
Cc: torvalds@osdl.org, adi@bitmover.com, scole@lanl.gov,
support@bitmover.com, linux-kernel@vger.kernel.org,
andrea@suse.de
Subject: Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)
Date: Sat, 15 May 2004 23:09:47 -0700 [thread overview]
Message-ID: <20040515230947.641685ca.akpm@osdl.org> (raw)
In-Reply-To: <200405152354.26083.elenstev@mesatop.com>
Steven Cole <elenstev@mesatop.com> wrote:
>
> > Hmm.. Th ecurrent BK tree contains much of the anonvma stuff, so this
> > might actually be a serious VM performance regression. That could
> > effectively be hiding whatever problem you saw.
>
> [steven@spc steven]$ vmstat -n 1 15
I have a feeling that the pageout performance got broken again, even more.
It was OK for a while and we need to backtrack and see where it went wrong.
The below might improve things, but I doubt it.
From: Nick Piggin <nickpiggin@yahoo.com.au>
If the zone has a very small number of inactive pages, local variable
`ratio' can be huge and we do way too much scanning. So much so that Ingo
hit an NMI watchdog expiry, although that was because the zone would have a
had a single refcount-zero page in it, and that logic recently got fixed up
via get_page_testone().
Nick's patch simply puts a sane-looking upper bound on the number of pages
which we'll scan in this round. It hasn't had a lot of thought or testing
yet.
---
25-akpm/mm/vmscan.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff -puN mm/vmscan.c~vm-shrink-zone mm/vmscan.c
--- 25/mm/vmscan.c~vm-shrink-zone 2004-05-15 23:08:36.471571816 -0700
+++ 25-akpm/mm/vmscan.c 2004-05-15 23:08:36.476571056 -0700
@@ -745,23 +745,29 @@ static int
shrink_zone(struct zone *zone, int max_scan, unsigned int gfp_mask,
int *total_scanned, struct page_state *ps, int do_writepage)
{
- unsigned long ratio;
+ unsigned long scan_active;
int count;
/*
* Try to keep the active list 2/3 of the size of the cache. And
* make sure that refill_inactive is given a decent number of pages.
*
- * The "ratio+1" here is important. With pagecache-intensive workloads
- * the inactive list is huge, and `ratio' evaluates to zero all the
- * time. Which pins the active list memory. So we add one to `ratio'
- * just to make sure that the kernel will slowly sift through the
- * active list.
+ * The "scan_active + 1" here is important. With pagecache-intensive
+ * workloads the inactive list is huge, and `ratio' evaluates to zero
+ * all the time. Which pins the active list memory. So we add one to
+ * `scan_active' just to make sure that the kernel will slowly sift
+ * through the active list.
*/
- ratio = (unsigned long)SWAP_CLUSTER_MAX * zone->nr_active /
- ((zone->nr_inactive | 1) * 2);
+ if (zone->nr_active >= 4*(zone->nr_inactive*2 + 1)) {
+ /* Don't scan more than 4 times the inactive list scan size */
+ scan_active = 4*max_scan;
+ } else {
+ /* Cast to long long so the multiply doesn't overflow */
+ scan_active = (unsigned long long)max_scan * zone->nr_active
+ / (zone->nr_inactive*2 + 1);
+ }
- atomic_add(ratio+1, &zone->nr_scan_active);
+ atomic_add(scan_active + 1, &zone->nr_scan_active);
count = atomic_read(&zone->nr_scan_active);
if (count >= SWAP_CLUSTER_MAX) {
atomic_set(&zone->nr_scan_active, 0);
_
next prev parent reply other threads:[~2004-05-16 6:10 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6616858C-A5AF-11D8-A7EA-000A95CC3A8A@lanl.gov>
[not found] ` <200405122234.06902.elenstev@mesatop.com>
[not found] ` <15594C37-A509-11D8-A7EA-000A95CC3A8A@lanl.gov>
[not found] ` <20040513183316.GE17965@bitmover.com>
2004-05-14 4:32 ` 1352 NUL bytes at the end of a page? Steven Cole
[not found] ` <20040514144617.GE20197@work.bitmover.com>
[not found] ` <200405131723.15752.elenstev@mesatop.com>
2004-05-14 16:53 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Andy Isaacson
2004-05-14 17:23 ` Steven Cole
2004-05-15 0:54 ` Steven Cole
2004-05-15 1:55 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-15 3:15 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Lincoln Dale
2004-05-15 3:41 ` Andrew Morton
2004-05-15 5:39 ` Steven Cole
2004-05-16 1:23 ` Steven Cole
2004-05-16 2:18 ` Linus Torvalds
2004-05-16 3:44 ` Linus Torvalds
2004-05-16 4:31 ` Steven Cole
2004-05-16 4:52 ` Linus Torvalds
2004-05-16 5:22 ` Andrea Arcangeli
2004-05-16 15:28 ` Steven Cole
2004-05-16 17:49 ` Rutger Nijlunsing
2004-05-16 20:38 ` Andrea Arcangeli
2004-05-16 21:19 ` Steven Cole
2004-05-16 21:29 ` Andrew Morton
2004-05-16 22:11 ` Steven Cole
2004-05-16 23:53 ` Andrea Arcangeli
2004-05-17 2:12 ` Steven Cole
2004-05-17 8:21 ` R. J. Wysocki
2004-05-16 5:54 ` Steven Cole
2004-05-16 6:09 ` Andrew Morton [this message]
2004-05-16 6:24 ` Andrew Morton
2004-05-16 10:01 ` Andrew Morton
2004-05-16 13:49 ` Steven Cole
2004-05-18 1:47 ` Benjamin Herrenschmidt
2004-05-16 3:20 ` Andrew Morton
2004-05-16 3:58 ` Linus Torvalds
2004-05-17 2:28 ` Larry McVoy
2004-05-17 2:42 ` Linus Torvalds
2004-05-17 3:36 ` Steven Cole
2004-05-17 5:17 ` Linus Torvalds
2004-05-17 6:11 ` Andrew Morton
2004-05-17 13:56 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-17 15:17 ` Theodore Ts'o
2004-05-17 15:20 ` Larry McVoy
2004-05-17 15:22 ` Linus Torvalds
2004-05-17 15:25 ` Larry McVoy
2004-05-17 15:37 ` viro
2004-05-17 17:30 ` Steven Cole
2004-05-17 17:40 ` viro
2004-05-17 17:39 ` Steven Cole
2004-05-17 19:06 ` viro
2004-05-17 15:40 ` Arjan van de Ven
2004-05-17 15:53 ` Steven Cole
2004-05-17 16:23 ` Davide Libenzi
2004-05-17 16:28 ` Davide Libenzi
2004-05-17 14:07 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Larry McVoy
2004-05-17 14:12 ` Linus Torvalds
2004-05-17 7:25 ` Andrew Morton
2004-05-17 7:46 ` Andrew Morton
2004-05-17 8:39 ` Vladimir Saveliev
2004-05-17 8:44 ` Andrew Morton
2004-05-17 11:58 ` Steven Cole
2004-05-17 14:05 ` Larry McVoy
2004-05-17 14:14 ` Larry McVoy
2004-05-17 14:32 ` Linus Torvalds
2004-05-17 14:52 ` Larry McVoy
2004-05-17 15:02 ` Linus Torvalds
2004-05-17 15:05 ` Larry McVoy
2004-05-17 15:23 ` Chris Mason
2004-05-17 15:49 ` Steven Cole
2004-05-17 20:24 ` Chris Mason
2004-05-17 21:08 ` Steven Cole
2004-05-17 21:29 ` Andrew Morton
2004-05-17 22:15 ` Steven Cole
2004-05-17 23:52 ` Steven Cole
2004-05-18 0:03 ` Chris Mason
2004-05-18 0:15 ` Andrew Morton
2004-05-18 0:13 ` Andrew Morton
2004-05-18 0:45 ` Steven Cole
2004-05-18 1:34 ` Larry McVoy
2004-05-18 1:42 ` Andrew Morton
2004-05-18 1:56 ` Steven Cole
2004-05-17 14:11 ` Larry McVoy
[not found] ` <200405172142.52780.elenstev@mesatop.com>
[not found] ` <Pine.LNX.4.58.0405172056480.25502@ppc970.osdl.org>
[not found] ` <200405172319.38853.elenstev@mesatop.com>
2004-05-18 12:42 ` Chris Mason
2004-05-18 14:29 ` Steven Cole
2004-05-18 14:38 ` Linus Torvalds
2004-05-19 10:53 ` Steven Cole
2004-05-19 12:10 ` Chris Mason
2004-05-19 12:20 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-19 12:42 ` Nick Piggin
2004-05-19 13:28 ` Steven Cole
2004-05-19 13:36 ` Chris Mason
2004-05-19 13:59 ` Steven Cole
2004-05-19 14:03 ` Wayne Scott
2004-05-19 14:08 ` Chris Mason
2004-05-19 14:20 ` Steven Cole
2004-05-19 14:45 ` Steven Cole
2004-05-19 21:11 ` Non-regression for current kernel (was Re: 1352 NUL bytes at the end of a page?) Steven Cole
2004-05-17 15:35 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Albert Cahalan
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=20040515230947.641685ca.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=adi@bitmover.com \
--cc=andrea@suse.de \
--cc=elenstev@mesatop.com \
--cc=linux-kernel@vger.kernel.org \
--cc=scole@lanl.gov \
--cc=support@bitmover.com \
--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 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.