From: Andrew Morton <akpm@zip.com.au>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: nonblocking-vm.patch
Date: Wed, 04 Sep 2002 14:46:45 -0700 [thread overview]
Message-ID: <3D767F45.97D8AAC9@zip.com.au> (raw)
In-Reply-To: Pine.LNX.4.44L.0209041832100.1857-100000@imladris.surriel.com
Rik van Riel wrote:
>
> On Wed, 4 Sep 2002, Andrew Morton wrote:
>
> > > But only if enough IO completes. Otherwise we'll just end
> > > up doing too much scanning for no gain again.
> >
> > Well we want to _find_ the just-completed IO, yes? Which implies
> > parking it onto the cold end of the inactive list at interrupt
> > time, or a separate list or something.
>
> In rmap14 I'm doing the following things when scanning the
> inactive list:
>
> 1) if the page was referenced, activate
> 2) if the page is clean, reclaim
OK. We need to start getting some of that stuff going now. We're
way too swappy at present. I'll merge up your NRU/dropbehind
patch soon. I imagine that you're waiting for me to stop changing
things.
> 3) if the page is written to disk, keep it at the end of
> the list where we start scanning from
hum. With the clustered-writeback-from-the-vm regime, this is
done over in mpage_writepages(). And that walks mapping->dirty_pages,
and moves the pages to the hot end of the inactive list (if they're
already on the inactive list).
I suppose we could just move them to the cold end and scan past them,
but that's a bit lazy.
They could be taken off the LRU altogether and reattached to the cold end
at IO completion.
But then, very little writeback actually happens from inside shrink_list.
> 4) if we don't write the page to disk (I don't submit too
> much IO at once) we move it to the far end of the inactive
> list
>
> This means that the pages for which IO completed will be found
> somewhere near the start of the list.
OK.
(Why don't you move them over to inactive_dirty? I've never understood
those two lists. I suspect the names are misleading?)
--
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-04 21:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-04 10:28 nonblocking-vm.patch Andrew Morton
2002-09-04 13:32 ` nonblocking-vm.patch Rik van Riel
2002-09-04 18:44 ` nonblocking-vm.patch Andrew Morton
2002-09-04 19:42 ` nonblocking-vm.patch Rik van Riel
2002-09-04 20:14 ` nonblocking-vm.patch Andrew Morton
2002-09-04 20:55 ` nonblocking-vm.patch Rik van Riel
2002-09-04 21:22 ` nonblocking-vm.patch Andrew Morton
2002-09-04 21:34 ` nonblocking-vm.patch Rik van Riel
2002-09-04 21:46 ` Andrew Morton [this message]
2002-09-04 22:12 ` nonblocking-vm.patch Rik van Riel
2002-09-04 22:41 ` nonblocking-vm.patch Andrew Morton
2002-09-04 22:46 ` nonblocking-vm.patch Rik van Riel
2002-09-05 5:43 ` nonblocking-vm.patch Andrew Morton
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=3D767F45.97D8AAC9@zip.com.au \
--to=akpm@zip.com.au \
--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 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.