David Rientjes <rient...@google.com> writes:
> On Tue, 17 Jul 2012, Andrew Morton wrote:
>
>> > > Commit a6bc32b899223a877f595ef9ddc1e89ead5072b8 ('mm: compaction:
>> > > introduce
>> > > sync-light migration for use by compaction') change declaration of
>> > > migrate_pages() and migrate_huge_pages().
>> > > But, it miss changing argument of migrate_huge_pages()
>> > > in soft_offline_huge_page(). In this case, we should call with
>> > > MIGRATE_SYNC.
>> > > So change it.
>> > >
>> > > Additionally, there is mismatch between type of argument and function
>> > > declaration for migrate_pages(). So fix this simple case, too.
>> > >
>> > > Signed-off-by: Joonsoo Kim <js1...@gmail.com>
>> >
>> > Acked-by: David Rientjes <rient...@google.com>
>> >
>> > Should be cc'd to stable for 3.3+.
>>
>> Well, why? I'm suspecting a switch from MIGRATE_SYNC_LIGHT to
>> MIGRATE_SYNC will have no discernable effect. Unless it triggers hitherto
>> unknkown about deadlocks...
>>
>> For a -stable backport we should have a description of the end-user
>> visible effects of the bug. This changelog lacked such a description.
>>
>
> I would put this:
>
> MIGRATE_SYNC_LIGHT will not aggressively attempt to defragment memory when
> allocating hugepages for migration with MIGRATE_SYNC_LIGHT, such as not
> defragmenting dirty pages, so MADV_SOFT_OFFLINE and
> /sys/devices/system/memory/soft_offline_page would be significantly
> less successful without this patch.
Is that true with hugetlb pages ? hugetlbfs_migrate_page doesn't seem to
use the mode argument at all. We do look at MIGRATE_SYNC if we fail to
get page lock, but other than that do we look at mode argument for
hugetlb pages ?
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
