On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
>
> We also want to move the page to the per-address-space clean list in
> ClearPageDirty I suppose.
I would actually advice against this.
- it's ok to have too many pages on the dirty list (think o fthe dirty
list as a "these pages _can_ be dirty")
- whenever we do a ClearPageDirty() we're likely to remove the page from
the lists altogether, so it's not worth it doing extra work.
The exception, of course, is the actual "filemap_fdatasync()" function,
but that one would probably look something like
spin_lock(&page_cache_lock);
while (!list_empty(&mapping->dirty_pages)) {
struct page *page = list_entry(mapping->dirty_pages.next, struct page, list);
list_del(&page->list);
list_add(&page->list, &mapping->clean_pages);
if (!PageDirty(page))
continue;
page_get(page);
spin_unlock(&page_cache_lock);
lock_page(page);
if (PageDirty(page)) {
ClearPageDirty(page);
page->mapping->writepage(page);
}
UnlockPage(page);
page_cache_put(page);
spin_lock(&page_cache_lock);
}
spin_unlock(&page_cache_lock);
and again note how we can move it to the clean list early and we don't
have to keep the PageDirty bit 100% in sync with which list is it on. If
somebody marks it dirty later on (and the dirty bit is still set), that
somebody won't move it back to the dirty list (because it noticved that
the dirty bit is already set), but that's ok: as long as we do the
"ClearPageDirty(page);" call before startign the actual writeout(), we're
fine.
So the "mapping->dirty_pages" list is maybe not so much a _dirty_ list, as
a "scheduled for writeout" list. Marking the page clean doesn't remove it
from that list - it can happily stay on the list and then when the
writeout is started we'd just skip it.
Ok?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:12 EST