From: Rik van Riel <riel@conectiva.com.br>
To: Andrew Morton <akpm@zip.com.au>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: nonblocking-vm.patch
Date: Wed, 4 Sep 2002 19:46:39 -0300 (BRT) [thread overview]
Message-ID: <Pine.LNX.4.44L.0209041944510.1857-100000@imladris.surriel.com> (raw)
In-Reply-To: <3D768C12.6CEBDA74@zip.com.au>
On Wed, 4 Sep 2002, Andrew Morton wrote:
> Rik van Riel wrote:
> >
> > ...
> > Page_launder (shrink_cache) scans the inactive_dirty list.
> >
> > Pages which are ready to be reclaimed get moved to the inactive_clean
> > list, from where __alloc_pages() deals with them.
>
> The clang you heard was a penny. (Nickel? Dime?)
>
> So you have kswapd running page_launder most of the time, but under
> stress, page allocators will do it too.
kswapd (well, page_launde) moves pages from the inactive_dirty list to the
inactive_clean list. Page allocators grab pages from the inactive_clean
list.
> With all this infrastructure, we can tell beforehand whether
> a writeout will block. And I think that changes everything. It
> presumably means that we can get quite a bit smarter in there - if
> kswapd sees a non-blockingly-writeable mapping, go write it and move
> the pages <here>. If kswapd sees some dirty pages which might cause
> request queue blockage, then move them <there>. If the caller is _not_
> kswapd then blocking is sometimes desirable, so do something else.
Absolutely.
> I think I'm pretty much finished mangling vmscan.c (honest). Let
> me get the current stuff settled in and working not-completely-terribly,
> then you can get it working properly, OK? Should be a few days more..
>
> I'll leave the additional instrumentation in place for the while, find some
> way of getting the kernel to spit it out on demand.
Sounds great. Btw, what I have found is that once the right mechanism
is in place, additional tweaking of magic numbers achieves exactly ...
nothing.
A good mechanism balances itself.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
--
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 22: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 ` nonblocking-vm.patch Andrew Morton
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 ` Rik van Riel [this message]
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=Pine.LNX.4.44L.0209041944510.1857-100000@imladris.surriel.com \
--to=riel@conectiva.com.br \
--cc=akpm@zip.com.au \
--cc=linux-mm@kvack.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