Messages in this thread Patch in this message | | | Date | Tue, 4 May 2004 22:25:24 -0700 | From | Andrew Morton <> | Subject | Re: [VM PATCH 2.6.6-rc3-bk5] Dirty balancing in the presence of mapped pages |
| |
Shantanu Goel <sgoel01@yahoo.com> wrote: > > > In this case, given that we have an actively mapped > > MAP_SHARED pagecache > > page, marking it dirty will cause it to be written > > by pdflush. Even though > > we're not about to reclaim it, and even though the > > process which is mapping > > the page may well modify it again. This patch will > > cause additional I/O. > > > > True, but is that really very different from normal > file I/O where we actively balance # dirty pages? > Also, the I/O will only happen if the dirty thresholds > are exceeded. It probably makes sense though to skip > SwapCache pages to more closely mimic file I/O > behaviour.
We need to think about why real applications (as opposed to benchmarks) use MAP_SHARED. I suspect many of them will modify pages again and again and again. We really want to avoid writing these pages out until the application has truly finished with them.
I think it is probably the case that pages which were dirtied with write(2) are much less likely to be redirtied than pages which were dirtied via MAP_SHARED.
One thing you might like to look at is to give these pages another trip around the LRU after they have been unmapped from pagetables, and to give pdflush a poke. Add instrumentation to record how many pages end up getting written via vmscan's writepage versus via pdflush (use current_is_pdflush()).
diff -puN mm/vmscan.c~a mm/vmscan.c --- 25/mm/vmscan.c~a 2004-05-04 22:21:41.613856240 -0700 +++ 25-akpm/mm/vmscan.c 2004-05-04 22:23:16.016504856 -0700 @@ -318,7 +318,9 @@ shrink_list(struct list_head *page_list, rmap_unlock(page); goto keep_locked; case SWAP_SUCCESS: - ; /* try to free the page below */ + if (PageDirty(page)) + goto keep_locked; + break; } } rmap_unlock(page); _
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |