Messages in this thread | | | From | "braam" <> | Subject | RE: Buffer and page cache | Date | Sun, 7 Nov 1999 21:49:46 -0700 |
| |
Hi,
Sorry for my delayed reply. That was dumb of me not to check for followups.
sct@redhat.com wrote:
-> > What appears to be needed is the following - probably it's mostly -> > lacking in my understanding, but I'd appreciate to be advised how to -> > attack the following points: -> -> > - a bit to keep shrink_mmap away from the page. -> -> Yes, bumping the page count is the perfect way to do this.
If we do that, how can the VM still exert pressure to get rid of dirty pages?
-> -> > - a bit for a struct page that indicates the page needs to be written. -> > From block_write_full_page one could think that the PageUptoDate bit is -> > maybe the one to use. But does that really describe that this page is -> > "dirty" - as it is done for buffers. -> -> PageUpToDate can't be used: it is needed to flag whether the contents of -> the page are valid for a read. A written page must always be uptodate: -> !uptodate implies that we have created the page but are still reading it -> in from disk (or that the readin failed for some reason).
A "DirtyBit" in the page would give the VM the option of notifying file systems that have big caches to get rid of pages; now the count is irrelevant. Is that what shmfs does?
-> -> > - some indication of aging: we would like a pgflush daemon to walk the -> > dirty pages of the file system and write them back _after_ a little -> > while -> -> The fs should be able to manage that on its own. If you queue all of -> the pages which have been sent to the writepage() method, then you can -> flush to the physical disk whenever you want. A trivial bdflush -> lookalike in the fs itself can deal with that. -> -> You might well want a filesystem-private pointer in the page struct off -> which to hook any fs-specific data (such as your dirty page linked list -> pointers and the dirty flag). You will also need a way for the VM to -> exert memory pressure on those pages if it needs to reclaim memory. ->
Great I agree: a file system generic pointer would help a lot. Can we have it?
- Peter -
-> These are both things which ext3 will want anyway, so we should make -> sure that any infrastructure that gets put in place for this gets -> reviewed by all the different fs groups first. -> -> --Stephen ->
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |