Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucbvax!ucsfcgl!pixar!bp From: bp@pixar.UUCP Newsgroups: comp.sys.m6809 Subject: Re: on a Disk Cache for OS-9 Message-ID: <1002@pixar.UUCP> Date: Sun, 16-Aug-87 04:22:30 EDT Article-I.D.: pixar.1002 Posted: Sun Aug 16 04:22:30 1987 Date-Received: Sun, 16-Aug-87 22:14:24 EDT References: <5013@milano.UUCP> Reply-To: bp@pixar.UUCP (not him again!) Organization: Pixar -- Marin County, California Lines: 26 Keywords: OS9 CACHE SDOS In article <1114@wlbr.EATON.COM> Pete Lyall (wlbr!pete) writes, following up my posting <989@pixar.UUCP>: > What a resource management nightmare that would be! ... > Seems you'd spend as much time allocating & deallocating RAM > as doing anything else. Well, I started out thinking that you could hand memory between the cache and the rest of the system in reasonably large clusters - say 8K at a time, keeping them contiguous so that all of the RAM below a (moving) boundary address is owned by the system and all above is owned by the cache. The system gets 8K from the cache, and allocates from that until it's used up. Only when that 8K is used up or it needs a chunk larger than 8K would it ask the cache to move the boundary up. Only when it had more than 8K contiguous free space below the boundary would it surrender memory to the cache. That would reduce the overhead for SMALL memory allocations, but would introduce a `hiccup' once in a while, sort of like the hiccup Lisp gets when it does garbage collection. Memory fragmentation in the system would result in the boundary creeping ever higher. It would also be slow to start up a new process if a lot of dirty blocks had to be written out to get the memory. It would be even slower if those same blocks just flushed from cache had to be read in again to start the process! Back to the drawing board... bp