From: Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>
To: Christian Borntraeger
<borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
"Jason J. Herne"
<jjherne-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
qemu-devel <qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>,
"Dr. David Alan Gilbert"
<dgilbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Juan Quintela <quintela-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] mm: Loosen MADV_NOHUGEPAGE to enable Qemu postcopy on s390
Date: Thu, 19 Nov 2015 10:31:36 +0100 [thread overview]
Message-ID: <564D96F8.2020609@suse.cz> (raw)
In-Reply-To: <564D86AE.1010305-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
On 11/19/2015 09:22 AM, Christian Borntraeger wrote:
> On 11/18/2015 02:31 PM, Vlastimil Babka wrote:
>> [CC += linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
>> Anyway, I agree that it doesn't make sense to fail madvise when the given flag
>> is already set. On the other hand, I don't think the userspace app should fail
>> just because of madvise failing? It should in general be an advice that the
>> kernel is also strictly speaking free to ignore as it shouldn't affect
>> correctnes, just performance. Yeah, there are exceptions today like
>> MADV_DONTNEED, but that shouldn't apply to hugepages?
>> So I think Qemu needs fixing too.
>
> yes, I agree. David, Juan. I think The postcopy code should not fail if the madvise.
> Can you fix that?
>
> Also what happens if the kernel is build
>> without CONFIG_TRANSPARENT_HUGEPAGE? Then madvise also returns EINVAL,
>
> Does it? To me it looks more like we would trigger a kernel bug.
>
> mm/madvise.c:
> case MADV_HUGEPAGE:
> case MADV_NOHUGEPAGE:
> error = hugepage_madvise(vma, &new_flags, behavior); <-----
> if (error)
> goto out;
> break;
> }
>
>
> include/linux/huge_mm.h:
> static inline int hugepage_madvise(struct vm_area_struct *vma,
> unsigned long *vm_flags, int advice)
> {
> BUG();
> return 0;
> }
>
> If we just remove the BUG() statement the code would actually be correct
> in simply ignoring an MADVISE it cannot handle. If you agree, I can
> spin a patch.
Yeah this looks suspicious at first, but the code is not reachable
thanks to madvise_behavior_valid() returning false:
...
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
#endif
case MADV_DONTDUMP:
case MADV_DODUMP:
return true;
default:
return false;
I think the BUG() is pointless (KSM doesn't use it) but not wrong. I
wouldn't object to removal.
>
>
>> how does Qemu handle that?
>
> The normal qemu startup ignores the return value of the madvise. Only the
> recent post migration changes want to disable huge pages for userfaultd.
> And this code checks the return value. And yes, we should change that
> in QEMU.
Great, thanks :)
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
linux-s390@vger.kernel.org
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
aarcange@redhat.com, linux-api@vger.kernel.org,
linux-man@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH] mm: Loosen MADV_NOHUGEPAGE to enable Qemu postcopy on s390
Date: Thu, 19 Nov 2015 10:31:36 +0100 [thread overview]
Message-ID: <564D96F8.2020609@suse.cz> (raw)
In-Reply-To: <564D86AE.1010305@de.ibm.com>
On 11/19/2015 09:22 AM, Christian Borntraeger wrote:
> On 11/18/2015 02:31 PM, Vlastimil Babka wrote:
>> [CC += linux-api@vger.kernel.org]
>> Anyway, I agree that it doesn't make sense to fail madvise when the given flag
>> is already set. On the other hand, I don't think the userspace app should fail
>> just because of madvise failing? It should in general be an advice that the
>> kernel is also strictly speaking free to ignore as it shouldn't affect
>> correctnes, just performance. Yeah, there are exceptions today like
>> MADV_DONTNEED, but that shouldn't apply to hugepages?
>> So I think Qemu needs fixing too.
>
> yes, I agree. David, Juan. I think The postcopy code should not fail if the madvise.
> Can you fix that?
>
> Also what happens if the kernel is build
>> without CONFIG_TRANSPARENT_HUGEPAGE? Then madvise also returns EINVAL,
>
> Does it? To me it looks more like we would trigger a kernel bug.
>
> mm/madvise.c:
> case MADV_HUGEPAGE:
> case MADV_NOHUGEPAGE:
> error = hugepage_madvise(vma, &new_flags, behavior); <-----
> if (error)
> goto out;
> break;
> }
>
>
> include/linux/huge_mm.h:
> static inline int hugepage_madvise(struct vm_area_struct *vma,
> unsigned long *vm_flags, int advice)
> {
> BUG();
> return 0;
> }
>
> If we just remove the BUG() statement the code would actually be correct
> in simply ignoring an MADVISE it cannot handle. If you agree, I can
> spin a patch.
Yeah this looks suspicious at first, but the code is not reachable
thanks to madvise_behavior_valid() returning false:
...
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
#endif
case MADV_DONTDUMP:
case MADV_DODUMP:
return true;
default:
return false;
I think the BUG() is pointless (KSM doesn't use it) but not wrong. I
wouldn't object to removal.
>
>
>> how does Qemu handle that?
>
> The normal qemu startup ignores the return value of the madvise. Only the
> recent post migration changes want to disable huge pages for userfaultd.
> And this code checks the return value. And yes, we should change that
> in QEMU.
Great, thanks :)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
linux-s390@vger.kernel.org
Cc: aarcange@redhat.com, linux-man@vger.kernel.org,
Juan Quintela <quintela@redhat.com>,
linux-api@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
linux-mm@kvack.org, akpm@linux-foundation.org
Subject: Re: [Qemu-devel] [PATCH] mm: Loosen MADV_NOHUGEPAGE to enable Qemu postcopy on s390
Date: Thu, 19 Nov 2015 10:31:36 +0100 [thread overview]
Message-ID: <564D96F8.2020609@suse.cz> (raw)
In-Reply-To: <564D86AE.1010305@de.ibm.com>
On 11/19/2015 09:22 AM, Christian Borntraeger wrote:
> On 11/18/2015 02:31 PM, Vlastimil Babka wrote:
>> [CC += linux-api@vger.kernel.org]
>> Anyway, I agree that it doesn't make sense to fail madvise when the given flag
>> is already set. On the other hand, I don't think the userspace app should fail
>> just because of madvise failing? It should in general be an advice that the
>> kernel is also strictly speaking free to ignore as it shouldn't affect
>> correctnes, just performance. Yeah, there are exceptions today like
>> MADV_DONTNEED, but that shouldn't apply to hugepages?
>> So I think Qemu needs fixing too.
>
> yes, I agree. David, Juan. I think The postcopy code should not fail if the madvise.
> Can you fix that?
>
> Also what happens if the kernel is build
>> without CONFIG_TRANSPARENT_HUGEPAGE? Then madvise also returns EINVAL,
>
> Does it? To me it looks more like we would trigger a kernel bug.
>
> mm/madvise.c:
> case MADV_HUGEPAGE:
> case MADV_NOHUGEPAGE:
> error = hugepage_madvise(vma, &new_flags, behavior); <-----
> if (error)
> goto out;
> break;
> }
>
>
> include/linux/huge_mm.h:
> static inline int hugepage_madvise(struct vm_area_struct *vma,
> unsigned long *vm_flags, int advice)
> {
> BUG();
> return 0;
> }
>
> If we just remove the BUG() statement the code would actually be correct
> in simply ignoring an MADVISE it cannot handle. If you agree, I can
> spin a patch.
Yeah this looks suspicious at first, but the code is not reachable
thanks to madvise_behavior_valid() returning false:
...
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
#endif
case MADV_DONTDUMP:
case MADV_DODUMP:
return true;
default:
return false;
I think the BUG() is pointless (KSM doesn't use it) but not wrong. I
wouldn't object to removal.
>
>
>> how does Qemu handle that?
>
> The normal qemu startup ignores the return value of the madvise. Only the
> recent post migration changes want to disable huge pages for userfaultd.
> And this code checks the return value. And yes, we should change that
> in QEMU.
Great, thanks :)
next prev parent reply other threads:[~2015-11-19 9:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 15:18 [PATCH] mm: Loosen MADV_NOHUGEPAGE to enable Qemu postcopy on s390 Jason J. Herne
2015-11-12 16:45 ` Christian Borntraeger
2015-11-13 22:58 ` David Rientjes
[not found] ` <1447341516-18076-1-git-send-email-jjherne-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-11-18 13:31 ` Vlastimil Babka
2015-11-18 13:31 ` Vlastimil Babka
2015-11-19 8:22 ` Christian Borntraeger
2015-11-19 8:22 ` [Qemu-devel] " Christian Borntraeger
[not found] ` <564D86AE.1010305-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2015-11-19 9:31 ` Vlastimil Babka [this message]
2015-11-19 9:31 ` Vlastimil Babka
2015-11-19 9:31 ` Vlastimil Babka
2015-11-19 9:43 ` Dr. David Alan Gilbert
2015-11-19 9:43 ` [Qemu-devel] " Dr. David Alan Gilbert
2015-11-19 13:10 ` Dr. David Alan Gilbert
2015-11-19 14:30 ` Jason J. Herne
-- strict thread matches above, loose matches on Subject: below --
2015-11-11 15:35 Jason J. Herne
2015-11-11 17:30 ` Andrea Arcangeli
2015-11-11 19:47 ` Christian Borntraeger
2015-11-11 19:47 ` Christian Borntraeger
2015-11-11 20:42 ` Andrea Arcangeli
2015-11-11 20:42 ` Andrea Arcangeli
2015-11-11 20:01 ` Christian Borntraeger
2015-11-11 20:37 ` Andrea Arcangeli
2015-11-11 20:37 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564D96F8.2020609@suse.cz \
--to=vbabka-alswssmvlrq@public.gmane.org \
--cc=aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=dgilbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jjherne-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
--cc=quintela-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.