>: makes sense. My guess is that there is no real emulation
>: for madvise() right now. It uses the native madvise().
>: Adding a little wrapper that calls the native madvise()
>: and ignores the result would probably be the right thing
>: to do.

>That's just the problem:  we do have a madvise that _works_, we just don't
>do anything with the arguments it's passed.  madvise() exists for a program
>to say "pretty please try to keep these pages in-core" or "these pages can
>be swapped out at will".

I think there's a genuine semantic disagreement here.  If we have an
advisory function, likem advise(), that's implemented as a no-op, does
that count as an "mvadvise() that works"?

Really smart apps might want to do time/space tradeoffs -- use
different algorithms -- if they have an madvise(), versus having one
that isn't useful.  At least in the bad old days of Lisp and
small-memory, having vadvise() vs not might toggle how GC is done.
today, s/vadvise/madvise/


I dont know if madvise() is used for that, or if it would make such a
huge difference today, but if an app wants to try and tune VM
behaviour, _and_ change its behaviour accordingly, we should at least
let the app know if it's requests are being heard or ignored.
Shouldn't we?

And MADV_SPACEAVAIL looks like it should be more than just
advisory....  the manpage doesn't say, but is it supposed to give
reserve-backingstore-on-VM-allocation behaviour?