On Mon, Feb 13, 2012 at 11:22:26AM -0500, KOSAKI Motohiro wrote:
> > @@ -1181,8 +1258,22 @@ page_ok:
> > * When a sequential read accesses a page several times,
> > * only mark it as accessed the first time.
> > */
> > - if (prev_index != index || offset != prev_offset)
> > - mark_page_accessed(page);
> > + if (prev_index != index || offset != prev_offset) {
> > + int mode;
> > +
> > + mode = filemap_get_cache(mapping, index);
> > + switch (mode) {
> > + case FILEMAP_CACHE_NORMAL:
> > + mark_page_accessed(page);
> > + break;
> > + case FILEMAP_CACHE_ONCE:
> > + mark_page_usedonce(page);
> > + break;
> > + default:
> > + WARN_ON_ONCE(1);
> > + break;
>
> Here is generic_file_read, right? Why don't you care write and page fault?
That's correct. I focused in my read test case and have not consider
write and page fault at all yet. There's also another missing piece
probably: readahead.
About generic_file_read the behavior that we may want to provide looks
quite clear to me. Instead, I don't know which is the best behavior for
the NOREUSE writes... should we just avoid active lru list eligibility,
or also drop the pages after the write if they weren't present in page
cache before the write? In the former NOREUSE pages can still trash
pages in the inactive lru list, in the latter writes will be slow
because we need to wait for the writeback. Ideas/suggestions?
About readahead pages I think we shouldn't touch anything. IIUC, when
readahead pages are loaded in page cache for the first time they are
added to the inactive lru list and not marked as referenced.
If the readahead pages are also referenced by the application and
they're inside a NOREUSE range they won't be marked as referenced and
will continue to live in the inactive list (and dropped when the
inactive list is shrunk). If readahead pages are not inside a NOREUSE
range they will be treated as usual (marked as referenced, and moved to
the active list if they're accessed more than once).
Thanks,
-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
