linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <news-innominate.list.linux.mm@innominate.de>
To: linux-mm@kvack.org
Subject: Syncing the page cache, take 2
Date: Tue, 15 Aug 2000 10:32:14 +0200	[thread overview]
Message-ID: <news2mail-3999000E.4BED1557@innominate.de> (raw)

My earlier attempt to state the problem was not as clear as it could have been.

This is really a VFS problem not a mm problem per se, but since the two have
become so closely intertwined I'm bringing it up here.

There seems to be something missing in the current VFS (please correct me if I'm
wrong): the sync code totally ignores the page cache, so when you do a sync
you're only syncing the buffer cache and not file data that may have been mapped
into the page cache by file_write or file_mmap.

OK, if that is indeed the case then it needs to be fixed.

Since it needs to be fixed then this is a good time to state a particular need
that I have in my filesystem project: for optimal operation I need to be able to
sync the page cache to the buffer cache selectively.  An appropriate granularity
would be per-mapping.  So I would like to have a VFS call something like:

    void write_mapping_now (struct address_space *mapping, int sync)

This is modelled on the write_inode_now function.  (Not that I think that's the
greatest name in the world - I'm just trying to continue the pattern.)  The
exact semantics of write_mapping_now would likely be subject to considerable
discussion, but its effect on the page case is clear: for every dirty page in
the 
mapping address_space_operations->writepage should be called once.  This would
give me the syncing ability I need.

Arguably, write_mapping_now should be called by write_inode_now.

--
Daniel



-- 
Daniel
--
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  8:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-15  8:32 Daniel Phillips [this message]
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
     [not found] <3999C0C9.301BB475@innominate.de>
2000-08-15 22:21 ` 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=news2mail-3999000E.4BED1557@innominate.de \
    --to=news-innominate.list.linux.mm@innominate.de \
    --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