On 03/19/2015 06:30 AM, Gioh Kim wrote: > I tried to start compaction via /proc/sys/vm/compact_memory > as soon as I turned on my ARM-based platform. > But the compaction didn't start. > I found some variables in struct zone are not initalized. > > I think zone->compact_cached_free_pfn and some cache values for compaction > are initalized when the kernel starts compaction, not via > /proc/sys/vm/compact_memory. > If my guess is correct, an initialization are needed for that case. > > > Signed-off-by: Gioh Kim <gioh.kim@xxxxxxx> > --- > mm/compaction.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 8c0d945..944a9cc 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -1299,6 +1299,14 @@ static int compact_zone(struct zone *zone, struct compact_control *cc) > __reset_isolation_suitable(zone); > > /* > + * If this is activated by /proc/sys/vm/compact_memory > + * and the first try, cached information for compaction is not > + * initialized. > + */ > + if (cc->order == -1 && zone->compact_cached_free_pfn == 0) > + __reset_isolation_suitable(zone); > + > + /* > * Setup to move all movable pages to the end of the zone. Used cached > * information on where the scanners should start but check that it > * is initialised by ensuring the values are within zone boundaries. The code below this comment already does the initialization if the cached values are outside zone boundaries (e.g. due to not being initialized). So if I go through what your __reset_isolation_suitable(zone) call possibly fixes: - the code below comment should take care of zone->compact_cached_migrate_pfn and zone->compact_cached_free_pfn. - the value of zone->compact_blockskip_flush shouldn't affect whether compaction is done. - the state of pageblock_skip bits shouldn't matter for compaction via /proc/sys... as that sets ignore_skip_hint = true It might be perhaps possible that the cached scanner positions are close to meeting and compaction occurs but doesn't process much. That would be also true if both were zero, but at least on my x86 system, lowest zone's start_pfn is 1 so that would be detected and corrected. Maybe it is zero on yours though? (ARM?). So in any case, the problem should be identified in more detail so we know the fix is not accidental. It could be also worthwile to always reset scanner positions when doing a /proc triggered compaction, so it's not depending on what happened before. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>