Re: [PATCH] mm: Loosen MADV_NOHUGEPAGE to enable Qemu postcopy on s390

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 11.11.2015 um 18:30 schrieb Andrea Arcangeli:
> Hi Jason,
> 
> On Wed, Nov 11, 2015 at 10:35:16AM -0500, Jason J. Herne wrote:
>> MADV_NOHUGEPAGE processing is too restrictive. kvm already disables
>> hugepage but hugepage_madvise() takes the error path when we ask to turn
>> on the MADV_NOHUGEPAGE bit and the bit is already on. This causes Qemu's
> 
> I wonder why KVM disables transparent hugepages on s390. It sounds
> weird to disable transparent hugepages with KVM. In fact on x86 we
> call MADV_HUGEPAGE to be sure transparent hugepages are enabled on the
> guest physical memory, even if the transparent_hugepage/enabled ==
> madvise.

KVM on s390 does not support huge pages as of today, as it interfers with storage
keys and other extensions (like cooperative paging). The architectural place to 
store these extensions is in the page table extension, which do not exist with
lage pages. We have recently implemented keyless guests and working on additional
changes to allow large pages for guest backing - but not today.

>> new postcopy migration feature to fail on s390 because its first action is
>> to madvise the guest address space as NOHUGEPAGE. This patch modifies the
>> code so that the operation succeeds without error now.
> 
> The other way is to change qemu to keep track it already called
> MADV_NOHUGEPAGE and not to call it again. I don't have a strong
> opinion on this, I think it's ok to return 0 but it's a visible change
> to userland, I can't imagine it to break anything though. It sounds
> very unlikely that an app could error out if it notices the kernel
> doesn't error out on the second call of MADV_NOHUGEPAGE.

the sequence of
madvise (something); == ok
madvise (something); == EINVAL;
seems strange. So I think changing the kernel is the better approach.
> 
> Glad to hear KVM postcopy live migration is already running on s390 too.
> 
> Thanks,
> Andrea
> 
>>
>> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>

Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Who is going to take this patch? If I should take the patch, I need an
ACK from the memory mgmt folks.

Christian


>> ---
>>  mm/huge_memory.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index c29ddeb..a8b5347 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -2025,7 +2025,7 @@ int hugepage_madvise(struct vm_area_struct *vma,
>>  		/*
>>  		 * Be somewhat over-protective like KSM for now!
>>  		 */
>> -		if (*vm_flags & (VM_NOHUGEPAGE | VM_NO_THP))
>> +		if (*vm_flags & VM_NO_THP)
>>  			return -EINVAL;
>>  		*vm_flags &= ~VM_HUGEPAGE;
>>  		*vm_flags |= VM_NOHUGEPAGE;
>> -- 
>> 1.9.1