From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: "\"Benjamin C.R. LaHaise\" <blah@kvack.org> linux-mm"
<linux-mm@kvack.org>
Subject: Re: (reiserfs) Re: Maybe we can do 40 bits in June/July. (fwd)
Date: 22 Apr 1998 16:08:28 -0500 [thread overview]
Message-ID: <m1u37lo983.fsf@flinx.npwt.net> (raw)
In-Reply-To: "Benjamin C.R. LaHaise"'s message of Wed, 22 Apr 1998 14:29:18 -0400 (EDT)
>>>>> "BL" == Benjamin C R LaHaise <blah@kvack.org> writes:
BL> On 22 Apr 1998, Eric W. Biederman wrote:
BL> ...
>> My design:
>> As I understand it the buffer cache is fine, so it is just a matter
>> getting the page cache and the vma and the glue working.
BL> The buffer cache is currently fine, but we do want to get rid of it...
We already don't use it for reading files.
We just need to get the writing working better. Hopefully there can
come a merger between my write dirty pages in the page cache, and the
revamp of the current swapping code. Resulting in good write
performance.
Demand clearing of writes from the page cache when we need the page
works but it would be better to write the page first.
We probably also need a filesystem sync system call...
>> My thought is to make the page cache use generic keys.
>> This should help support things like the swapper inode a little
>> better. Still need a bit somewhere so we can coallese VMA's that have
>> an inode but don't need continous keys. That's for later.
BL> Hmmm, if you've seen my rev_pte patch then you'll notice that *all* vmas
BL> will soon need continuous keys...
I was recalling something about not putting an inode in private shared
mappings so the VMA's can be merged... That would be my definition of
non-continous keys. The keys don't have to be continous.
It would also be worth checking on your patch to see what happens when
someone calls mremap on a private shared area. I think you may have
key assignment problems...
This is from memory so I may be a little off. I think I also read an
older patch so I may be mixing my memories.
>> For the common case of inodes have the those keys:
page-> key == page->offset >> PAGE_SHIFT.
BL> Not a good idea unless support for a.out is dropped completely -- a better
BL> choice would be to use 512 as a divisor; then pages can at least be at the
BL> block offset as needed by a.out.
How is a.out read in? Private mapping of any alignment can still
(theoretically) be handled. Sharing private mappings is more
complicated, we need a COW scheme (for the page cache). Currently
generic_file_mmap is broken with regard to private mappings...
BL> Something else to keep in mind is that we also need a mechanism to keep
BL> metadata in the page cache (rather, per-inode metadata; fixed metadata can
BL> just use its own inode).
In the short run for large file support I'd like to keep the changes
as small as possible.
In the long run I want a generic backing store object (which an inode
could be a superset of) being the backing store for the page cache.
per-inode metada... The indirect blocks... ACL.. Got it.
Eric
prev parent reply other threads:[~1998-04-22 21:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-04-22 13:18 Rik van Riel
1998-04-22 17:57 ` Eric W. Biederman
1998-04-22 18:29 ` Benjamin C.R. LaHaise
1998-04-22 21:08 ` 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=m1u37lo983.fsf@flinx.npwt.net \
--to=ebiederm+eric@npwt.net \
--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