On Wed, 30 Sep 1998, Jonathan Stone wrote:

: >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 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?

I've never seen madvise() used to change the behavior of the program; it's
certainly possible, but I have only seen it used as its advisory function
(most often on mmaped memory regions used as variable or database storage).
It is usually there to get a "hopeful performance boost".

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.

: 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?

AFAIK, MADV_SPACEAVAIL, which isn't even in the SunOS/SVR4 implementations
of madvise(), is there to make sure page maps are created for a mapped
object or region.  This would essentially be a no-op too, as we do that
anyway, even if the mapped object is MAP_ANON (which gets zero-filled pages 
automagically).

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