MAP_SHARED handling

MAP_SHARED handling

[Andrew Morton]

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

Re: MAP_SHARED handling

[Rik van Riel]

On Thu, 5 Sep 2002, Andrew Morton wrote:

> One thing bugs me a little bit.

> - We'll be calling ->vm_writeback() once per page, and it'll only
>   discover a single dirty page on swapper_space.dirty_pages.

> 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?

FreeBSD is doing this and seems to be getting good results
with it, so I guess it'll improve our VM too ;)

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

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

Re: MAP_SHARED handling

[Daniel Phillips]

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/

Re: MAP_SHARED handling

[Andrew Morton]

Daniel Phillips wrote:
> 
> ...
> 
> 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.

Good point.  Marking the pages dirty and not starting IO on them
exposes them to pdflush.  Chances are, by the time those pages
come around again, they'll all be under writeback or clean.

And, umm, yes.  If a pass across all the zones in the classzone
doesn't free enough stuff, we run wakeup_bdflush() and then
take an up-to-quarter-second nap.  So pdflush will immediately
start working on all those pages which we just marked dirty.
It looks about right.
--
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/