Re: [RFC][PATCH 1/3] tracking dirty pages in shared mappings -V4

[Christoph Lameter <clameter@sgi.com>]

On Thu, 11 May 2006, Andrew Morton wrote:

> > It survives a simple test and shows the dirty pages in /proc/vmstat.
> 
> It'd be nice to have more that a "simple test" done.  Bugs in this area
> will be subtle and will manifest in unpleasant ways.  That goes for both
> correctness and performance bugs.

Standard tests such as AIM7 will not trigger these paths. It is rather
unusual for small unix processes to have a shared writable mapping and 
therefore I doubt that the typical benchmarks may show much of a 
difference. These  types of mappings are more typical for large or 
specialized apps. Be sure that the tests actually do dirty 
pages in shared writeable mappings.

> > +int page_wrprotect(struct page *page)
> > +{
> > +	int ret = 0;
> > +
> > +	BUG_ON(!PageLocked(page));
> 
> hm.  So clear_page_dirty() and clear_page_dirty_for_io() are only ever
> called against a locked page?  I guess that makes sense, but it's not a
> guarantee which we had in the past.  It really _has_ to be true, because
> lock_page() is the only thing which can protect the address_space from
> memory reclaim in those two functions.

If that is true then we can get rid of atomic ops in both functions.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>