linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@conectiva.com.br>
To: Daniel Phillips <daniel.phillips@innominate.de>
Cc: linux-mm@kvack.org
Subject: Re: Syncing the page cache, take 2
Date: Tue, 15 Aug 2000 19:21:53 -0300 (BRST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0008151916160.2466-100000@duckman.distro.conectiva> (raw)
In-Reply-To: <3999C0C9.301BB475@innominate.de>

On Wed, 16 Aug 2000, Daniel Phillips wrote:
> Rik van Riel wrote:
> > On Tue, 15 Aug 2000, Stephen C. Tweedie wrote:
> > 
> > > Correct.  We have plans to change this in 2.5, basically by
> > > removing the VM's privileged knowledge about the buffer cache
> > > and making the buffer operations (write-back, unmap etc.) into
> > > special cases of generic address-space operations.  For 2.4,
> > > it's really to late to do anything about this.
> > 
> > please take a look at my VM patch at http://www.surriel.com/patches/
> > (either the -test4 or the -test7-pre4 one).
> > 
> > If you look closely at mm/vmscan.c::page_launder(), you'll see
> > that we should be able to add the flush callback with only about
> > 5 to 10 lines of changed code ...
> > 
> > (and even more ... we just about *need* the flush callback when
> > we're running in a multi-queue VM)
> 
> OK, but what about the case where the filesystem knows it wants
> the page cache to flush *right now*?  For example, when a
> filesystem wants to be sure the page cache is synced through to
> buffers just before marking a consistent state in the journal,
> say.  How does it make that happen?

There are some ugly tricks, like pinning the buffer so that
the buffer flushing code can't flush it out. Most of these
have the potential for messing up VM and making the box run
out of memory or even making the box hang...

If the new VM makes it into 2.4, however, it should be
relatively easy to add the flush callback as a function
in page_launder(). Otherwise we could add yet another
thing to shrink_mmap() ... we could do it, but I guess
at the cost of some code readability  *grin*

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.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.eu.org/Linux-MM/

       reply	other threads:[~2000-08-15 22:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3999C0C9.301BB475@innominate.de>
2000-08-15 22:21 ` Rik van Riel [this message]
2000-08-15  8:32 Daniel Phillips
2000-08-15 18:46 ` Stephen C. Tweedie
2000-08-15 18:58   ` Rik van Riel
     [not found]     ` <news2mail-3999C0C9.301BB475@innominate.de>
2000-08-16 20:49       ` Stephen C. Tweedie
2000-08-16 21:06         ` 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=Pine.LNX.4.21.0008151916160.2466-100000@duckman.distro.conectiva \
    --to=riel@conectiva.com.br \
    --cc=daniel.phillips@innominate.de \
    --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