Subject: Re: CVS commit: src
To: None <firstname.lastname@example.org>
From: Michael L. Hitch <email@example.com>
Date: 09/30/1998 13:30:33
On Sep 30, 2:40pm, Todd Vierling wrote:
> 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
According to the DEC Unix manpage:
Only a few values of the behav parameter values are operational on Digital
UNIX systems. Non-operational values cause the system to always return
> : [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.
> 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.
DEC Unix defines this, but doesn't say exactly what it does, or even if
it does anything (see above NOTES):
Ensure that resources are reserved
Michael L. Hitch firstname.lastname@example.org
Information Technology Center
Montana State University Bozeman, MT USA