From: Andrew Morton <akpm@digeo.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: Rik van Riel <riel@conectiva.com.br>,
William Lee Irwin III <wli@holomorphy.com>,
sfkaplan@cs.amherst.edu, linux-mm@kvack.org
Subject: Re: [PATCH] modified segq for 2.5
Date: Mon, 09 Sep 2002 15:58:06 -0700 [thread overview]
Message-ID: <3D7D277E.7E179FA0@digeo.com> (raw)
In-Reply-To: E17oXIx-0006vb-00@starship
Daniel Phillips wrote:
>
> On Monday 09 September 2002 11:38, Andrew Morton wrote:
> > One thing this patch did do was to speed up the initial untar of
> > the kernel source - 50 seconds down to 25. That'll be due to not
> > having so much dirt on the inactive list. The "nonblocking page
> > reclaim" code (needs a better name...)
>
> Nonblocking kswapd, no? Perhaps 'kscand' would be a better name, now.
Well, it blocks still. But it doesn't block on "this particular
request queue" or on "that particular page ending IO". It
blocks on "any queue putting back a write request". Which is
basically equivalent to blocking on "a bunch of pages came clean".
This logic is too global at present. It really needs to be per-zone,
to fix an oom problem which you-know-who managed to trigger. All
ZONE_NORMAL is dirty, we keep on getting woken up by IO completion in ZONE_HIGHMEM, we end up scanning enough ZONE_NORMAL pages to conclude
that we're oom. (Plus I reduced the maximum-scan-before-oom by 2.5x)
Then again, Bill had twiddled the dirty memory thresholds
to permit 12G of dirty ZONE_HIGHMEM.
> > ...does that in 18 secs.
>
> Woohoo! I didn't think it would make *that* much difference, did you
> dig into why?
That's nuthin. Some tests are 10-50 times faster. Tests like
trying to compile something while some other process is doing a
bunch of big file writes.
> My reason for wanting nonblocking kswapd has always been to be able to
> untangle the multiple-simultaneous-scanners mess, which we are now in
> a good position to do. Erm, it never occurred to me it would be as easy
> as checking whether the page *might* block and skipping it if so.
>
Skipping is dumb. It shouldn't have been on that list in the
first place.
--
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/
next prev parent reply other threads:[~2002-09-09 22:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-15 14:24 [PATCH] modified segq for 2.5 Rik van Riel
2002-09-09 9:38 ` Andrew Morton
2002-09-09 11:40 ` Ed Tomlinson
2002-09-09 17:10 ` William Lee Irwin III
2002-09-09 18:58 ` Andrew Morton
2002-09-09 13:10 ` Rik van Riel
2002-09-09 19:03 ` Andrew Morton
2002-09-09 19:25 ` Rik van Riel
2002-09-09 19:55 ` Andrew Morton
2002-09-09 20:03 ` Rik van Riel
2002-09-09 20:51 ` Andrew Morton
2002-09-09 20:57 ` Andrew Morton
2002-09-09 21:09 ` Rik van Riel
2002-09-09 21:52 ` Andrew Morton
2002-09-09 22:41 ` Rik van Riel
2002-09-10 0:17 ` Daniel Phillips
2002-09-09 22:49 ` William Lee Irwin III
2002-09-09 22:54 ` Rik van Riel
2002-09-09 23:32 ` William Lee Irwin III
2002-09-09 23:53 ` Rik van Riel
2002-09-09 22:46 ` Daniel Phillips
2002-09-09 22:58 ` Andrew Morton [this message]
2002-09-09 23:40 ` William Lee Irwin III
2002-09-10 0:02 ` Andrew Morton
2002-09-10 0:21 ` William Lee Irwin III
2002-09-10 1:13 ` Andrew Morton
2002-09-10 1:50 ` Daniel Phillips
2002-09-10 2:02 ` Rik van Riel
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=3D7D277E.7E179FA0@digeo.com \
--to=akpm@digeo.com \
--cc=linux-mm@kvack.org \
--cc=phillips@arcor.de \
--cc=riel@conectiva.com.br \
--cc=sfkaplan@cs.amherst.edu \
--cc=wli@holomorphy.com \
/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.