Messages in this thread | | | Date | Wed, 05 May 2004 13:16:33 +1000 | From | Nick Piggin <> | Subject | Re: [VM PATCH 2.6.6-rc3-bk5] Dirty balancing in the presence of mapped pages |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >>Andrew Morton wrote: >> >>>Shantanu Goel <sgoel01@yahoo.com> wrote: >>> >>> >>>>Presently the kernel does not collection information >>>>about the percentage of memory that processes have >>>>dirtied via mmap until reclamation. Nothing analogous >>>>to balance_dirty_pages() is being done for mmap'ed >>>>pages. The attached patch adds collection of dirty >>>>page information during kswapd() scans and initiation >>>>of background writeback by waking up bdflush. >>> >>> >>>And what were the effects of this patch? >>> >> >>I havea modified patch from Nikita that does the >>if (ptep_test_and_clear_dirty) set_page_dirty from >>page_referenced, under the page_table_lock. > > > Dude. I have lots of patches too. The question is: what use are they? > > 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. > > So we need to understand why it was written, and what effects were > observed, with what workload, and all that good stuff. >
I guess it is an attempt to do somewhat better at dirty page accounting for mmap'ed pages. The balance_dirty_pages_ratelimited writeout path also has the same problem as you describe. Maybe usage patterns means this is less of an issue here?
But I suppose it wouldn't be nice to change without seeing some improvement somewhere.
> >>It doesn't do the wakeup_bdflush thing, but that sounds >>like a good idea. What does wakeup_bdflush(-1) mean? > > > It appears that it will cause pdflush to write out down to > dirty_background_ratio. >
Yeah. So wakeup_bdflush(0) would be more consistent? - 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/
| |