Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Re: Disk cache
Message-ID: <8706022203.AA26928@cogsci.berkeley.edu>
Date: Tue, 2-Jun-87 18:03:54 EDT
Article-I.D.: cogsci.8706022203.AA26928
Posted: Tue Jun  2 18:03:54 1987
Date-Received: Fri, 5-Jun-87 00:36:04 EDT
References: <344@cmbvax.cbmvax.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 66


In article <> cbmvax!andy@harvard.harvard.EDU typed:
>>	- Intercepts AllocMem to invalidate some cache buffers
> This method sounds like a bad thing...you will have memory that
> isn't really free, and isn't really used.  (tristate memory ?)

Agreed.  There is a problem with other solutions (read on)


>---------
> [make] a library (called memory.library or something) that keeps track of
> memory for the buffers.
> [when exec needs memory it will call the expunge vector which]
> when called causes the library to invalidate all buffers and throw them away.

Here is a major gripe I have had with expunge.  Exec will call it when it is
low on memory, but does not say HOW low.  Without some fancy stuff one would
have to flush all the cache blocks... waseful.   If the exec call to
expunge would specify HOW much memory is needed, a deal could be struck.
(1.3? Please?!)


>---------
> Then, to improve performance, fire up a task which uses the [allocation]
> calls to give finer control.
> That task could be running at a fairly high priority, checking memory usage,
> and adding and/or subtracting buffers as memory requirements change.

Ok, that will do for now.  But the system really has a better idea of what the
memory situation is like.   It can also prevent thrashing between competing
ideas of "high and low water marks".
In addition to the size mentioned above
I would like to see a PRIORITY attached to expungeable stuff.  For example
512 cache buffers are quite expendible, a cache of just a directory is somewhat
less and an actual library less still.  Non-libraries may want to get into the
act also, say a wordprocessor that can edit any size file but uses an area
of RAM to hold of the part that is currently active.  (ie. WORDPERFECT etc.).


My pick would be a set of extensions to exec to allow all this dynamic memory
mangement (sic).  PRIORITIES, VOLATILITIES and AMOUNTS.
(How volatile is that request? Will it be deallocated in a few micros or does
that plan on hang{_ing around for hours/days?)


>-------
>You could use AbsAllocate to make it use memory from the top down.

Semi-related.  Could AllocMem initially refuse to break up a large block with
a small request, and instead skip ahead to a smaller block later on?  From
the standpoint of fragmentation large and small requests would seem to want
to be kept somewhat separate.


>-------
>andy finkel		{ihnp4|seismo|allegra}!cbmvax!andy 

cbmvax is invisible from here unless  cmbvax!user@harvard.harvard.EDU  is used.


-------------
         Ack!  (NAK,EOT,SOH)
 |\ /|  .
 {o O} .  bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
 ( " ) 
   U      Single tasking?  Just say *NO!*