* Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> Hi
>
> "libvhost-user: madvises for postcopy" for ex, would be nicer imho
Done.
> On Thu, Aug 24, 2017 at 12:27 PM, Dr. David Alan Gilbert (git)
> <dgilb...@redhat.com> wrote:
> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> > Clear the area and turn off THP.
> >
> > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > ---
> > contrib/libvhost-user/libvhost-user.c | 32 ++++++++++++++++++++++++++++++--
> > 1 file changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/contrib/libvhost-user/libvhost-user.c
> > b/contrib/libvhost-user/libvhost-user.c
> > index 5ec54f7d60..d816851c6d 100644
> > --- a/contrib/libvhost-user/libvhost-user.c
> > +++ b/contrib/libvhost-user/libvhost-user.c
> > @@ -450,11 +450,39 @@ vu_set_mem_table_exec(VuDev *dev, VhostUserMsg *vmsg)
> > }
> >
> > if (dev->postcopy_listening) {
> > + int ret;
> > /* We should already have an open ufd need to mark each memory
> > * range as ufd.
> > - * Note: Do we need any madvises? Well it's not been accessed
> > - * yet, still probably need no THP to be safe, discard to be
> > safe?
> > */
> > +
> > + /* Discard any mapping we have here; note I can't use
> > MADV_REMOVE
> > + * or fallocate to make the hole since I don't want to lose
> > + * data that's already arrived in the shared process.
> > + * TODO: How to do hugepage
> > + */
> > + ret = madvise((void *)dev_region->mmap_addr,
> > + dev_region->size + dev_region->mmap_offset,
> > + MADV_DONTNEED);
> > + if (ret) {
> > + fprintf(stderr,
> > + "%s: Failed to madvise(DONTNEED) region %d: %s\n",
> > + __func__, i, strerror(errno));
> > + }
> > + /* Turn off transparent hugepages so we dont get lose wakeups
> > + * in neighbouring pages.
> > + * TODO: Turn this backon later.
> > + */
> > + ret = madvise((void *)dev_region->mmap_addr,
> > + dev_region->size + dev_region->mmap_offset,
> > + MADV_NOHUGEPAGE);
> > + if (ret) {
> > + /* Note: This can happen legally on kernels that are
> > configured
> > + * without madvise'able hugepages
> > + */
> > + fprintf(stderr,
> > + "%s: Failed to madvise(NOHUGEPAGE) region %d:
> > %s\n",
> > + __func__, i, strerror(errno));
> > + }
> > struct uffdio_register reg_struct;
> > reg_struct.range.start = (uintptr_t)dev_region->mmap_addr;
> > reg_struct.range.len = dev_region->size +
> > dev_region->mmap_offset;
> > --
> > 2.13.5
> >
>
> Errors are non-fatal? patch looks ok to me, despite the TODOs :).
The DONTNEED is actually not critical in this case; since we've
only just mmap'd it there should be nothing mapped in there that
needs clearing with DONTNEED; however it's a good safe guard.
There's no equivalent syscall we can make for postcopy.
The madvise(NOHUGEPAGE) can fail on a kernel that's configured
without CONFIG_TRANSPARENT_HUGEPAGE_MADVISE if TRANSPARENT_HUGEPAGE=n
then that's OK since it just means we don't have transparent hugepages
and thus we can't turn them off (I think we saw this on s390 or aarch64)
if CONFIG_TRANSAPRENT_HUGEPAGE_ALWAYS is set then things get
messy. IMHO there's way too many kernel config flags for transparent
hugepages!
> Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Thanks,
Dave
>
>
>
>
> --
> Marc-André Lureau
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
