Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!frankenstein.cis.ohio-state.edu!meranda
From: meranda@frankenstein.cis.ohio-state.edu (deron meranda)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ramdrive repacking
Message-ID: <88966@tut.cis.ohio-state.edu>
Date: 27 Feb 91 20:02:24 GMT
References: <88002@tut.cis.ohio-state.edu> <19286@cbmvax.commodore.com>
Sender: news@tut.cis.ohio-state.edu
Reply-To: deron meranda <meranda@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 75

In article <19286@cbmvax.commodore.com>
  darren@cbmvax.commodore.com (Darren Greenwald) writes:
>In article <88002@tut.cis.ohio-state.edu>
  <meranda@iguana.cis.ohio-state.edu> writes:
>>...
>
>    RAM: - the ram-handler (allocates memory dynamically; not a device).
>    RAD: - the ramdrive.device (allocates a big chunk of contiguous memory)
>
> So the answer to the original question is, RAD: doesn't have this problem,
> but it eats up a big chunk of contiguous memory up-front.  RAM: can fragment
> your memory, but it only uses what it needs.  A give, and take situation.
> I suppose that a ram drive like RAM: could try to defragment itself, but
> you can easily get into a no-win situation; you start trading off
> non-contiguous chunks of memory for contiguous ones, and still end-up
> eating large chunks of contiguous memory, leaving little ones free.
>
>	 ---Darren---

Thanks for recognizing the difference between RAD: and RAM:.  Perhaps
I wasn't clear on my original posting.  It really _wouldn't_ make much
sense for the ramdrive to defragment itself by moving all the files
into contiguous memory chunks - as you noticed.

However, I assume that the ramdrive uses something similar to blocks
to divide the files into small pieces, and links them via some kind
of memory pointer (perhaps even BPTR's).  Except for the controversy
over fast and chip memory (or virtual memory if anything supports it),
it should make no difference how these blocks are scattered throughout
memory from the ramdrive's perspective - i.e. contiguous chunks don't
mean much.

Now consider what the rest of the system sees - namely the free system
memory chunks.  It is desirable for these to be as large as possible.
Lets use a real simple picture for a senerio:

          `R'  is memory used by the ramdrive
          `.'  is free system memory
          `x'  is memory used by something else

   1)  Initial conditions:

       ..RRR.xxx.xxx..RR.............R...

   2)  System gets heavily loaded:

       xxRRR.xxx.xxxxxRR.xxxxx.xxxxxxRxxx

   3)  A program appends data to a RAM: file:

       xxRRR.xxx.xxxxxRR.xxxxxRxxxxxxRxxx
                              ^

   4)  The system load lightens again:

       ..RRR.xxx.xxx..RR......R......R...

Now, that one block used by the ramdrive is cutting that big free
memory block in half!  And YES -- This does happen often to me.

What I would like, is upon recognizing that condition, is to execute
(perhaps manually) a program which attempts to move that lone block
into some smaller free memory chunk.  It would be perfectly acceptable
to sacrifice system performance while that moving is being done.
Note, that the ramdrive is still technically just as fragmented -
but the "free memory" is not as fragmented.

Does this clear up what I meant?  I seems to me that this should be
very possible without too many difficulties -- if one has some
insights into the ramdrive formats itself.  Can anyone help or
comment on this idea?

Thanks in advance.

Deron E. Meranda  ( meranda@cis.ohio-state.edu )