Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Jul 2018 18:47:25 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 230160] linuxulator doesn't implement madvise(MADV_DONTNEED) correctly
Message-ID:  <bug-230160-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230160

            Bug ID: 230160
           Summary: linuxulator doesn't implement madvise(MADV_DONTNEED)
                    correctly
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: markj@FreeBSD.org

Our emulation of Linux's madvise(2) appears to just call sys_madvise()
directly:

{ AS(madvise_args), (sy_call_t *)sys_madvise, AUE_MADVISE, NULL, 0, 0, 0,
SY_THR_STATIC },

This sort of works for the "standard" MADV_* constants since their values a=
re
the same on FreeBSD and Linux.  However, Linux has a somewhat surprising
behaviour for MADV_DONTNEED: if applied to a mapping of anonymous memory, t=
he
next access will return a zero-filled page.  That is, applying MADV_DONTNEED
causes eager reclamation of pages in the range.  In contrast, our MADV_DONT=
NEED
implementation just causes affected pages to skip LRU, and our MADV_FREE al=
lows
lazy reclamation of affected pages.  Some popular software, e.g., jemalloc,
expects Linux's behaviour and won't work as expected under the Linuxulator
because it just passes the parameters straight through to the native madvis=
e(2)
implementation.

Some of Linux's other advice parameters are implemented on FreeBSD using
minherit(2) (e.g., MADV_WIPEONFORK, MADV_DONTFORK).

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230160-227>