> For nefarious reasons of my own, I'm interested in keeping buffer usage
> constant, in a system with only the rd block device. I've started out by
> populating the ram disk with an un-holey filesystem image, and from there
> it does a good job of not using more or less memory -- with one exception.
>
> I finally figured out what was causing a bizarre "leak": the bforget
> function which is invoked by ext2/truncate.c -- and _only_ by that code,
> at least in 2.0.33. In the process of truncating a file, bforget is
> invoked on the discarded buffers, which removes the protected bits (thus
> turning the pages loose from the ram disk), and resets the device numbers
> to zero without moving the page to the free list. The former is just
> annoying, but the latter seems to have the fairly bizarre effect of
> leaving "zombie" clean buffers around that, as far as I can tell, will not
> be reclaimed or reused by anything short of try_to_free_buffer, or the
> inner machinations of refill_freelist.
The try_to_free_buffer() and refill_free_list are the normal mechanisms by
which buffer pages are reclaimed, so you don't have to be worried about
losing pages.
There are some dangers to using RAM disks apart from just a boot time -- the
system memory management uses the percentage of buffer memory as a guide for
when to free buffers, but doesn't know that protected buffers can't be freed.
This might lead to situations where the system has reclaimed virtually all of
the general-purpose buffers, but still thinks there's lots of buffer memory.
The RAM disk buffers also make the buffer hash chains longer, increasing the
time to search for other general-purpose buffers.
> So, two questions: can I replace bforget in the ext2 code with something
> else, brelse perhaps? (It's not obvious whether their semantics are
> identical.) Secondly, am I mistaken about forgotten pages, and are they
> reclaimable via some process I've missed?
The semantics are most certainly not identical -- bforget is used when you
want to get rid of a buffer's identity, as its block on disk has just be
released. The truncate code goes to pains to ensure that the buffer won't get
accidentally reused before it can be forgotten.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html