Re: Kernel: /dev/ram1 (rd.c) not releasing unused memory automatically any more?

From: Peter T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 11/16/05 

Date: Wed, 16 Nov 2005 12:01:01 +0100

Daniel Kabs <daniel.kabs@gmx.de> wrote:
> Hello Tauno Voipio,

> thanks for getting back to me. :-)

> Tauno Voipio wrote:
>> There is one point: A demand-paged virtual memory system
>> does not allocate physical memory at allocation time. The
>> physical memory is allocated only when it is accessed, when
>> the kernel checks whether to give a page or trap for an
>> illegal access.

> Therefore my malloc() programm does not only mallocate the memory but
> also writes to it. This makes sure that all the allocated memory is also
> mapped to physical memory.

No no no. "Physical memory" does not equate to "the ram disk". PLEASE
take on board what I and others are saying to you. All you are doing is
dirtying buffers - the ram disk never gets to see them, just as your hard
disk never gets to see the writes to buffers that are aimed at the IDE
driver, until a long time later. "Buffers" as far as IDE disks are
concerned is precisely the count of writes that are NOT ON THE DISK YET,
and the same is true of the ram driver, with the exception that the ram
driver, when it eventually "gets" the write that long time later, does not
transfer the data out of the buffer, so no change of accounting stats is
seen.

>> This applies also to memory for the RAM disks.

> Please bear with me, but data written to a file on the ram disk does
> have to be stored somewhere. And this is physical memory which is now
> dirty/allocated/busy/used, isn't it?

Of course, but that's irrelevant. The only thing the RAM driver does is
mark temporary buffers as permanent. There is no change of state
involved, only a change of METASTATE, and you are completely disregarding
that change, which is the only thing the ram driver does.

Before that change occurs, the buffers are temporary, and will evaporate
after removing their referents, which is what removing the file to which
you wrote does. After it, they will stay around, even if you remove the
file.

You are not taking ANY of this into account, and it is so simple!

>> To complicate things, there are memory blocks used for
>> saving physical disk blocks for cacheing. ...

> I think, this is not relevant in my case: my system has no hard drive at
> all.

It's completely relevant, given that your ramdisk is a block device, just
like all other disks!

Peter

Relevant Pages

  • Re: How does free() knows?
    ... > are typically stored on disk; if you allocate more than the amount ... > of physical memory, your program is going to slow down as it swaps ... > data between disk and memory. ... is to remove the batteries and reinsert them. ...
    (comp.lang.c)
  • Re: How does free() knows?
    ... > are typically stored on disk; if you allocate more than the amount ... > of physical memory, your program is going to slow down as it swaps ... > data between disk and memory. ... is to remove the batteries and reinsert them. ...
    (comp.lang.cpp)
  • Re: Get System Memory in C
    ... >>Just not to risk to allocate something in vitual memory. ... > program got this info and force that memory to disk. ... > they just allocated 10 times more physical memory than was available. ...
    (comp.lang.c)
  • Re: unexpected shut down in window vista
    ... > - check if you have adequate disk space. ... > - If a driver is identified in the stop message, ... > Initializing disk for crash dump. ... > Beginning dump of physical memory. ...
    (microsoft.public.windows.vista.general)
  • Re: free (command) memory question
    ... > I just ran the free command and it shows as follows: ... Of the used memory 105MB is buffers and 213MB ... would assume Linux always keeps a little physical memory for buffers and ... cache, so I would expect it to start swapping before all of the additional ...
    (alt.os.linux.suse)