From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Mike Simons <msimons@moria.simons-clan.com>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: More observations...
Date: Tue, 16 May 2000 17:07:07 +0100 [thread overview]
Message-ID: <20000516170707.B30047@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0005161228030.30661-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Tue, May 16, 2000 at 12:41:05PM -0300
Hi,
On Tue, May 16, 2000 at 12:41:05PM -0300, Rik van Riel wrote:
>
> > The concept is quite simple: if you can limit a process's RSS,
> > you can limit the amount of memory which is pinned in process
> > page tables, and thus subject to expensive swapping. Note that
> > you don't have to get rid of the pages --- you can leave them in
> > the page cache/swap cache, where they can be re-faulted rapidly
> > if needed, but if the memory is needed for something else then
> > shrink_mmap can reclaim the pages rapidly.
>
> There's one problem with this idea. The current implementation
> of shrink_mmap() skips over dirty pages, leading to a failing
> shrink_mmap(), calls to swap_out() and replacement of the wrong
> pages...
No, because if you have evicted the pages from the RSS, they are
guaranteed to be clean. The shrink_mmap reclaim will never have
to block. We always flush mmaped or anon pageson swapout, not on
shrink_mmap().
For writable shared file mappings, the flush only goes to the buffer
cache, not to disk, so we still rely on bdflush writeback, but
currently filemap_swapout triggers the bdflush thread automatically
anyway. Subsequent shrink_mmap reclaims will just find a locked
page and block, which is the desired behaviour.
--Stephen
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-05-16 16:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-16 2:44 More observations Mike Simons
2000-05-16 10:20 ` Stephen C. Tweedie
2000-05-16 15:41 ` Rik van Riel
2000-05-16 16:07 ` Stephen C. Tweedie [this message]
2000-05-16 17:23 ` 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=20000516170707.B30047@redhat.com \
--to=sct@redhat.com \
--cc=linux-mm@kvack.org \
--cc=msimons@moria.simons-clan.com \
--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.