Messages in this thread | | | Date | Fri, 10 Aug 2012 17:49:34 +0900 | From | Minchan Kim <> | Subject | Re: [PATCH 2/5] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures |
| |
On Thu, Aug 09, 2012 at 02:49:22PM +0100, Mel Gorman wrote: > If allocation fails after compaction then compaction may be deferred for > a number of allocation attempts. If there are subsequent failures, > compact_defer_shift is increased to defer for longer periods. This patch > uses that information to scale the number of pages reclaimed with > compact_defer_shift until allocations succeed again. The rationale is > that reclaiming the normal number of pages still allowed compaction to > fail and its success depends on the number of pages. If it's failing, > reclaim more pages until it succeeds again. > > Note that this is not implying that VM reclaim is not reclaiming enough > pages or that its logic is broken. try_to_free_pages() always asks for > SWAP_CLUSTER_MAX pages to be reclaimed regardless of order and that is > what it does. Direct reclaim stops normally with this check. > > if (sc->nr_reclaimed >= sc->nr_to_reclaim) > goto out; > > should_continue_reclaim delays when that check is made until a minimum number > of pages for reclaim/compaction are reclaimed. It is possible that this patch > could instead set nr_to_reclaim in try_to_free_pages() and drive it from > there but that's behaves differently and not necessarily for the better. If > driven from do_try_to_free_pages(), it is also possible that priorities > will rise. When they reach DEF_PRIORITY-2, it will also start stalling > and setting pages for immediate reclaim which is more disruptive than not > desirable in this case. That is a more wide-reaching change that could > cause another regression related to THP requests causing interactive jitter. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > Acked-by: Rik van Riel <riel@redhat.com> Reviewed-by: Minchan Kim <minchan@kernel.org>
-- Kind regards, Minchan Kim
| |