Re: [VM PATCH] rotate_reclaimable_page fails frequently

[Shantanu Goel <sgoel01@yahoo.com>]

--- Marcelo Tosatti <marcelo.tosatti@cyclades.com>
wrote:

> Hi Shantanu,
> 

Hi Marcelo.

> I guess that big issue here is that the pgrotate
> logic is completly
> useless for common cases (and no one stepped up to
> fix it, here's a
> chance).
> 

I am all for this.  The motivation in my case is the
VM scanner seems to be rather severe on mapped memory
in the case where the inactive list is full of dirty
pages.  For instance, with the default values of
swappiness (60), dirty_background_ratio (10) and
dirty_ratio (40), if the mapped memory is just under
the 80% mark, the unmapped_ratio logic in
page-writeback.c does not kick in with the dd test I
described in my original email.  Now most pages
encountered by kswapd will be dirty.  One scan will
require pushing these pages to the backing store. 
However, generic_buffered_write() marks all dirty
pages as referenced with the result, it will take 2
iterations before any I/O is performed since the
scanner skips inactive/dirty/referenced pages.  This
causes the priority to drop enough that we start
reclaiming mapped memory.  What's worse is we scan
mapped memory at a higher priority.  Reducing
swappiness does not help completely because that
effectively increases the priority at which we do the
first mapped scan.

Ideally, for workloads that want to avoid paging as
much as possible, we should perhaps have a mode where
we never activate unmapped pages and let them all
reside on the inactive list.  mark_page_accessed()
would simply move an unmapped page to the head of the
inactive list on the 2nd reference.  The page scanner
would then reclaim unmapped pages in a strict LRU
fashion regardless of whether the page is dirty.  I
have a patch that implements this but it does not
perform well for dbench type workloads so a special
/proc/sys/vm option enables/disables it.  If there is
any interest I can post it.

> Marking PG_writeback pages as PG_rotated once
> they're chosen candidates
> for eviction increases the number of rotated pages
> dramatically, but
> that does not necessarily increase performance (I
> was unable to see any
> performance increase under the limited testing I've
> done, even though
> the pgrotated numbers were _way_ higher).

It is a win for the "most memory is mapped with
occasional large file copying" scenario in my
experience.  The patch I mentioned above does this as
well.

> 
> Another issue is that increasing the number of
> rotated pages increases
> lru_lock contention, which might not be an advantage
> for certain
> workloads.

The code as posted is certainly sub-optimal in this
regard.  I have not given this much thought yet but
you do raise a good point.

Shantanu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
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/