Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA (Jim Giles)
Newsgroups: net.arch
Subject: Re: VERY LARGE main memories
Message-ID: <7832@lanl.ARPA>
Date: Tue, 23-Sep-86 19:29:13 EDT
Article-I.D.: lanl.7832
Posted: Tue Sep 23 19:29:13 1986
Date-Received: Wed, 24-Sep-86 22:02:52 EDT
References: <1130@bu-cs.bu-cs.BU.EDU> <7144@lanl.ARPA> <7148@lanl.ARPA> <7094@utzoo.UUCP> <7331@lanl.ARPA> <2077@sdcsvax.UUCP>
Reply-To: jlg@a.UUCP (Jim Giles)
Organization: Los Alamos National Laboratory
Lines: 33

In article <2077@sdcsvax.UUCP> hutch@sdcsvax.UUCP (Jim Hutchison) writes:
>...
>vmadvise() ???  I don't think BSD ever got it fully off of the ground, but
>it has interesting applications to you.  It was a way of sharing your
>specific paging knowledge which is bought by time, with the OS.  This will
>not save you from page translation cost, but it does allow you to advise
>the OS on differences your program has from the general case.  It also allows
>the OS to play any strange games that can be played to squeeze those extra
>pennies out of your XXXXX.
>
My document lists this as VADVISE().  It only has two settings which,
apparently, optimize for random order (that is, it ignores the recent
usage patterns), or it optimizes for the most frequently and recently
referenced pages (the default).  The MAN page contains a note that
this feature was included mainly to support LISP, which has fairly
random access patterns.

This doesn't seem to give the kind of control over memory contents that
I am used to.  It certainly doesn't seem likely to work well for an
algorithm that has some 'randomly' used data, some cyclically used data,
and some frequently used data (or some such mix).

The VADVISE() doc also mentions (under 'BUGS') that this 'Will go away
soon, being replaced by a per page *madvise* facility.' MADVISE looks
like it will have more control over memory contents (but still not
complete control).  It looks also like it will entail the same degree
of work to use it effectively as direct user control would require.
So the bottom line is: we still don't have complete control, we still
need to do a lot of work on our own, and we still have a slower memory
interface than necessary.

J. Giles
Los Alamos