Subject: Re: CVS commit: src
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Todd Vierling <firstname.lastname@example.org>
Date: 09/30/1998 14:04:17
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
-- Todd Vierling (Personal email@example.com; Bus. firstname.lastname@example.org)