Hugh Dickins <[email protected]> wrote:
>
> zap_pte_range already avoids wasting time to mark_page_accessed on anon
> pages: it can also skip anon set_page_dirty - the page only needs to be
> marked dirty if shared with another mm, but that will say pte_dirty too.
>
Are you sure about this?
> --- mm03/mm/memory.c 2005-09-24 19:26:38.000000000 +0100
> +++ mm04/mm/memory.c 2005-09-24 19:27:05.000000000 +0100
> @@ -574,12 +574,14 @@ static void zap_pte_range(struct mmu_gat
> addr) != page->index)
> set_pte_at(tlb->mm, addr, pte,
> pgoff_to_pte(page->index));
> - if (pte_dirty(ptent))
> - set_page_dirty(page);
> if (PageAnon(page))
> dec_mm_counter(tlb->mm, anon_rss);
> - else if (pte_young(ptent))
> - mark_page_accessed(page);
> + else {
> + if (pte_dirty(ptent))
> + set_page_dirty(page);
> + if (pte_young(ptent))
> + mark_page_accessed(page);
> + }
> tlb->freed++;
> page_remove_rmap(page);
> tlb_remove_page(tlb, page);
What is the page is (for example) clean swapcache, having been recently
faulted in. If this pte indicates that this process has modified the page
and we don't run set_page_dirty(), the page could be reclaimed and the
change is lost.
Or what is the page was an anon page resulting from (say) a swapoff, and
it's shared by two mm's and one has modified it and we drop that dirty pte?
Or <other scenarios>.
Need more convincing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |