[lkml]   [2011]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/5] Reduce compaction-related stalls...
Hi Mel,

these are the last compaction/MM related patches I'm using, to me it
looks like the latest changes regressed the reliability of compaction,
and with the below I seem to get good reliability instead.

The __GFP_NO_KSWAPD would also definitely regress it by preventing
sync compaction to run which is fundamental to make the movable
pageblock really movable. This further improves it by making sure sync
compaction is always run (see patch 4/8) but it also reduces the
migration overhead (see patch 5/8).

I think it'd be good to test 5/8 and see if it reduces the stalls a
bit with the usb stick writes. Probably it won't be enough but it
still worth a try and it sounds good idea anyway.

The direction in allowing async compaction to migrate all type of
pages (so we don't screw the movable pageblock) is good, but the
version you posted had blocker bugs so I think this is safer as a
start and you can hack it on top of this if you want. Until we have
that working really well, the __GFP_NO_KSWAPD patch isn't good idea

[PATCH 1/8] mm: compaction: Allow compaction to isolate dirty pages
[PATCH 2/8] mm: compaction: Use synchronous compaction for /proc/sys/vm/compact_memory
[PATCH 3/8] mm: check if we isolated a compound page during lumpy scan
[PATCH 4/8] mm: compaction: defer compaction only with sync_migration
[PATCH 5/8] mm: compaction: avoid overwork in migrate sync mode
[PATCH 6/8] Revert "mm: compaction: make isolate_lru_page() filter-aware"
[PATCH 7/8] Revert "vmscan: abort reclaim/compaction if compaction can proceed"
[PATCH 8/8] Revert "vmscan: limit direct reclaim for higher order allocations"

btw, my aa tree on includes the above.

 \ /
  Last update: 2011-11-19 20:57    [W:0.103 / U:5.688 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site