Re: MAP_SHARED handling

[Daniel Phillips <phillips@arcor.de>]

On Thursday 05 September 2002 09:20, Andrew Morton wrote:
> One thing bugs me a little bit.
> 
> A program has a huge MAP_SHARED segment and dirties it.  The VM
> walks the LRU, propagating the pte dirtiness into the pageframe
> and *immediately* writes the page out:
> 
> 	switch (try_to_unmap(page))
> 	case SWAP_SUCCESS:
> 		break;
> 	}
> 
> 	if (PageDirty(page))
> 		vm_writeback(page->mapping);
> 
> This has a few small irritations.
> 
> - We'll be calling ->vm_writeback() once per page, and it'll only
>   discover a single dirty page on swapper_space.dirty_pages.
> 
>   This is a little CPU-inefficient.  Be nicer to build up a few
>   dirty pages on swapper_space before launching vm_writeback
>   against it.
> 
> - My dirty page accounting tells lies.  In /proc/meminfo, `Dirty'
>   is just a few tens of kilobytes, and `Writeback' is a meg or two.
> 
>   But in reality, there are a huge number of dirty pages - we just
>   don't know about them yet.
> 
>   And there's some benefit in making `Dirty' more accurate, because
>   that will cause balance_dirty_pages() to clamp down harder on
>   write(2) callers.
> 
> 
> So....  Could we do something like: if the try_to_unmap() call turned
> the page from !PageDirty to PageDirty, give it another go around the
> list?

Why not just ensure the page is scheduled for writing, sometime,
we don't care exactly when as long as it's relatively soon.  Just bump
the page's mapping to the hot end of your writeout list and let things
take their course.

-- 
Daniel
--
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/