From: "Benjamin C.R. LaHaise" <blah@kvack.org>
To: Magnus Ahltorp <map@stacken.kth.se>
Cc: linux-mm@kvack.org
Subject: Re: MM question
Date: Wed, 24 Feb 1999 12:36:11 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.3.95.990224120401.25235C-100000@as200.spellcast.com> (raw)
In-Reply-To: <ixdn2266t22.fsf@turbot.pdc.kth.se>
On 22 Feb 1999, Magnus Ahltorp wrote:
> Right now, an Arla inode has some extra information, containing a
> dentry for the cache file. The readpage() function just validates the
> cache information, fills in a struct file (with the ext2 inode) and
> calls ext2's readpage(). The struct page pointer is passed along to
> ext2's readpage() without any modifications.
Okay, you probably don't want to implement readpage, just read and write,
so your read will look like:
my_read(...)
{
validate_cache();
return cache_inode->read(cache_inode, ...)
}
The write operation should be something like:
my_write(...)
{
validate_cache_for_write();
down(&cache_inode->i_sem);
cache_inode->write(cache_inode, ...)
up(&cache_inode->i_sem);
}
This will make your inodes relatively lightweight, and avoid having in
memory pages attached to your inode which would be duplicates of those
attached to the ext2 inode.
> I don't really know what's supposed to happen during a readpage()
> call, and what I want is a way to make write() affect the pages that
> readpage() has read.
Readpage is called by generic_file_read and page fault handlers to pull
the page into the page cache. In the case of writing, you need to update
the page cache, as well as commit the write to whatever backstore is used.
Since you've got the entire file cached (right?), just making use of the
ext2 inode's read & write will keep the cache coherent and reduce the
amount work you need to do.
> (I might sound somewhat disoriented, but that is because I am)
You're asking questions, so the hard part is over =)
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-02-24 17:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-21 19:53 Magnus Ahltorp
1999-02-21 21:34 ` Benjamin C.R. LaHaise
1999-02-22 21:13 ` Magnus Ahltorp
1999-02-24 17:36 ` Benjamin C.R. LaHaise [this message]
1999-02-24 17:55 ` Magnus Ahltorp
1999-03-15 18:05 ` Stephen C. Tweedie
-- strict thread matches above, loose matches on Subject: below --
1999-02-16 2:30 Jason Titus
1999-02-18 15:06 ` Stephen C. Tweedie
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.3.95.990224120401.25235C-100000@as200.spellcast.com \
--to=blah@kvack.org \
--cc=linux-mm@kvack.org \
--cc=map@stacken.kth.se \
/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