[PATCH] madvise.2: MADV_WIPEONFORK affects semantics

[PATCH] madvise.2: MADV_WIPEONFORK affects semantics

[agl]

Include MADV_WIPEONFORK in the list of advice values that have a
semantic impact on the calling process.
---
  man2/madvise.2 | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/man2/madvise.2 b/man2/madvise.2
index a0f3a477a..6c25f697a 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -84,21 +84,23 @@ values have been added.
  The
  .I advice
  values listed below
  allow an application to tell the kernel how it expects to use
  some mapped or shared memory areas, so that the kernel can choose
  appropriate read-ahead and caching techniques.
  These
  .I advice
  values do not influence the semantics of the application
  (except in the case of
-.BR MADV_DONTNEED ),
+.BR MADV_DONTNEED
+and
+.BR MADV_WIPEONFORK ),
  but may influence its performance.
  All of the
  .I advice
  values listed here have analogs in the POSIX-specified
  .BR posix_madvise (3)
  function, and the values have the same meanings, with the exception of
  .BR MADV_DONTNEED .
  .PP
  The advice is indicated in the
  .I advice
-- 
2.26.0

Re: [PATCH] madvise.2: MADV_WIPEONFORK affects semantics

[Jakub Wilk]

Hi Adam!

* Adam Langley <agl@google.com>, 2020-04-28, 17:40:
> These
> .I advice
> values do not influence the semantics of the application
> (except in the case of
>-.BR MADV_DONTNEED ),
>+.BR MADV_DONTNEED
>+and
>+.BR MADV_WIPEONFORK ),
> but may influence its performance.

This sentence is in the "Conventional advice value" subsection, which 
defines only MADV_NORMAL, MADV_RANDOM, MADV_SEQUENTIAL, MADV_WILLNEED, 
and MADV_DONTNEED.

MADV_WIPEONFORK is defined in the "Linux-specific advice values" 
subsection, which already notes that "some of these operations change 
the semantics of memory accesses". (Perhaps s/some/most/ would be better 
wording.)

-- 
Jakub Wilk

Re: [PATCH] madvise.2: MADV_WIPEONFORK affects semantics

[Michael Kerrisk (man-pages)]

Hello Jakub (and Adam),

On Tue, 28 Apr 2020 at 20:09, Jakub Wilk <jwilk@jwilk.net> wrote:
>
> Hi Adam!
>
> * Adam Langley <agl@google.com>, 2020-04-28, 17:40:
> > These
> > .I advice
> > values do not influence the semantics of the application
> > (except in the case of
> >-.BR MADV_DONTNEED ),
> >+.BR MADV_DONTNEED
> >+and
> >+.BR MADV_WIPEONFORK ),
> > but may influence its performance.
>
> This sentence is in the "Conventional advice value" subsection, which
> defines only MADV_NORMAL, MADV_RANDOM, MADV_SEQUENTIAL, MADV_WILLNEED,
> and MADV_DONTNEED.

(Good catch.)

> MADV_WIPEONFORK is defined in the "Linux-specific advice values"
> subsection, which already notes that "some of these operations change
> the semantics of memory accesses".

<nod>

> (Perhaps s/some/most/ would be better
> wording.)

Perhaps you are right. Here's my take:

Do change memory semantics:
MADV_REMOVE
MADV_DONTFORK / MADV_DOFORK
MADV_HWPOISON
MADV_FREE
MADV_WIPEONFORK

Don't change memory semantics:
MADV_MERGEABLE / MADV_UNMERGEABLE
MADV_SOFT_OFFLINE
MADV_HUGEPAGE / MADV_NOHUGEPAGE
MADV_DONTDUMP / MADV_DODUMP

Do you agree?

"Some" is perhaps a little loose, but perhaps "most" is overstating
it, so I'm not quite sure what to do here. Perhaps ad a line to each
of the operations in the first category noting that the operations
change memory semantics. THoughts?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] madvise.2: MADV_WIPEONFORK affects semantics

[Adam Langley]

On Tue, Apr 28, 2020 at 11:09 AM Jakub Wilk <jwilk@jwilk.net> wrote:
> This sentence is in the "Conventional advice value" subsection, which
> defines only MADV_NORMAL, MADV_RANDOM, MADV_SEQUENTIAL, MADV_WILLNEED,
> and MADV_DONTNEED.
>
> MADV_WIPEONFORK is defined in the "Linux-specific advice values"
> subsection, which already notes that "some of these operations change
> the semantics of memory accesses". (Perhaps s/some/most/ would be better
> wording.)

Ah, thank you! Now that I look with that in mind, it makes sense.


AGL