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
> sufficient.

  According to the DEC Unix manpage:

NOTES

  Only a few values of the behav parameter values are operational on Digital
  UNIX systems.  Non-operational values cause the system to always return
  success (zero).

> : [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.
> 
> Hm.
> 
> 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):

            MADV_SPACEAVAIL
                      Ensure that resources are reserved


Michael

-- 
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA