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. > 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. Glad to hear KVM postcopy live migration is already running on s390 too. Thanks, Andrea > > Signed-off-by: Jason J. Herne <jjherne@xxxxxxxxxxxxxxxxxx> > --- > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
