lkml.org 
[lkml]   [2004]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [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/

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