lkml.org 
[lkml]   [1999]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Buffer and page cache
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.040 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site