From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: "Benjamin C.R. LaHaise" <blah@kvack.org>
Cc: linux-mm@kvack.org
Subject: Re: VM support for transaction processing
Date: 18 Jun 1998 19:45:36 -0500 [thread overview]
Message-ID: <m11zsmxlqn.fsf@flinx.npwt.net> (raw)
In-Reply-To: "Benjamin C.R. LaHaise"'s message of Sat, 25 Apr 1998 11:33:49 -0400 (EDT)
>>>>> "BL" == Benjamin C R LaHaise <blah@kvack.org> writes:
BL> On Fri, 24 Apr 1998, Peter J. Braam wrote:
BL> ...
BL> Hmmm, looking at filemap_swapin: shouldn't it wait for the page to become
BL> unlocked before allowing the user to make use of the mapping?
A) Yes
B) It doesn't matter because nothing currently in the kernel writes
pages directly out from the page cache yet...
BL> Should the
BL> write semantics of mmapings be cleaned up before 2.2? I'm thinking of a
BL> small set of changes: write protect pages when beginning to write them out
BL> to disk (to avoid the performance hit on the normal case, have a hint bit
BL> in page->flags if the page has any writable mappings), and make
BL> filemap_swapin wait for the page to become !Locked && Uptodate.
Since the page is being written the page is garanteed to be Uptodate.
Since we currently don't write things through the page cache we don't
need to worry about it being locked.
For really implementing writes through the page cache I have to tackle
all of these issues. The write protect sounds good, but you need to
watch for other code that will notice it is allowed to be a writeable
mapping and convert it.
It also has the problem of when to decrement the page count, which is
primarily what the current mechanism gives us. So changing it is
tricky.
Eric
prev parent reply other threads:[~1998-06-19 0:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.96.980424174134.891C-100000@carissimi.coda.cs.cmu.edu>
1998-04-25 15:33 ` Benjamin C.R. LaHaise
1998-06-19 0:45 ` Eric W. Biederman [this message]
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=m11zsmxlqn.fsf@flinx.npwt.net \
--to=ebiederm+eric@npwt.net \
--cc=blah@kvack.org \
--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