On Wed, 30 Sep 1998, Jonathan Stone wrote:

: >And after all of that, there is nowhere a documented guarantee that the
: >advice about memory usage actually does anything beneficial, particularly on
: >higher load machines.
: 
: Uh, that is precisely where the semantic disagreement over "advisory"
: is.  Does 'advisory' mean reasonable best-effort, or is a total no-op
: good enough?

According to Solaris's own manpage:

     madvise() advises the kernel that a region  of  user  mapped
     memory in the range [addr, addr + len) will be accessed fol-
     lowing a type of pattern.  The kernel uses this  information
     to  optimize  the procedure for manipulating and maintaining
     the resources associated with the specified mapping range.

It goes on to describe Solaris's behavior for each option, all of which
involve different handling of how (or whether) pages are retained in cache.

IMHO, this seems to indicate that best effort is good, and no-op is
sufficient.

: [MADV_SPACEAVAIL]
: 
: The manpage doesnt say.  I thought it meant backing-store, so that you
: know at malloc() time whether you actually get the space you want,
: rather than losing when you try and write into a zfod page.
: I've seen code which exploits that.

Hm.

I can't seem to find an implementation which uses this, so I can't tell
whether to define it as:

- no-op, since the address has to be in the extant virtual address space of
  the program (so if you call this before sbrk(), you lose);
- the equivalent of doing an sbrk() on the region.

Perhaps I could:

- let the first five flags pass through as no-ops
  (MADV_NORMAL-MADV_DONTNEED), which also go for emulations of these five
  widelyt-used ops, until a real backing implementation exists;
- on MADV_SPACEAVAIL, return EOPNOTSUPP (pending the above);
- on FreeBSD's MADV_FREE (their op 5), translate to MADV_DONTNEED;
- sanity-check the op on emulated madvise()s (for now, we match them all for
  ops 0-4, and only FreeBSD has an op 5, which is different)

?

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)