summaryrefslogtreecommitdiffstats
path: root/mm/memory.c
diff options
context:
space:
mode:
authorJohannes Weiner <hannes@cmpxchg.org>2013-02-22 16:32:19 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2013-02-23 17:50:09 -0800
commit9b4f98cdac9683ee9cdb28c582a81223f0c10a3f (patch)
treebca65df9e9bca718b7afc4fb15c56d104e0ba346 /mm/memory.c
parent9a2651140ef740b3b67ad47ea3d0af75581aacc6 (diff)
downloadop-kernel-dev-9b4f98cdac9683ee9cdb28c582a81223f0c10a3f.zip
op-kernel-dev-9b4f98cdac9683ee9cdb28c582a81223f0c10a3f.tar.gz
mm: vmscan: compaction works against zones, not lruvecs
The restart logic for when reclaim operates back to back with compaction is currently applied on the lruvec level. But this does not make sense, because the container of interest for compaction is a zone as a whole, not the zone pages that are part of a certain memory cgroup. Negative impact is bounded. For one, the code checks that the lruvec has enough reclaim candidates, so it does not risk getting stuck on a condition that can not be fulfilled. And the unfairness of hammering on one particular memory cgroup to make progress in a zone will be amortized by the round robin manner in which reclaim goes through the memory cgroups. Still, this can lead to unnecessary allocation latencies when the code elects to restart on a hard to reclaim or small group when there are other, more reclaimable groups in the zone. Move this logic to the zone level and restart reclaim for all memory cgroups in a zone when compaction requires more free pages from it. [akpm@linux-foundation.org: no need for min_t] Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Rik van Riel <riel@redhat.com> Acked-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Michal Hocko <mhocko@suse.cz> Cc: Hugh Dickins <hughd@google.com> Cc: Satoru Moriya <satoru.moriya@hds.com> Cc: Simon Jeons <simon.jeons@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/memory.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud