Subject: Re: CVS commit: src
To: Todd Vierling <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/30/1998 10:07:00
>: 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.
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.
And MADV_SPACEAVAIL looks like it should be more than just
advisory.... the manpage doesn't say, but is it supposed to give