lkml.org 
[lkml]   [1998]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Questions: bforget & forgotten pages
On Fri, 28 Aug 1998, Stephen C. Tweedie wrote:

> Hi,
>
> On Fri, 28 Aug 1998 09:18:45 -0400 (EDT), Kenneth Albanowski
> <kjahds@kjahds.com> said:
> > And I'm still at a loss to understand why this forgetting process is
> > needed: the buffer _always_ represents what is on disk, or had better
> > do so, so this isn't a sync operation.
>
> > My best guess so far is that this is related to not bothering with writing
> > out data that is immaterial (orphaned indirect i-nodes). But this is
> > strictly an optimization (and perhaps a help to un-erasers), so replacing
> > bforget with brelse would be safe, correct?
>
> Yes. It's entirely a performance issue. With respect to ramdisks, it
> has another very important effect: forgotten buffers can be reclaimed by
> the VM system, but other ramdisk buffers are pinned in memory. This
> allows us to reclaim ramdisk memory when we delete files (important now
> that we allocate ramdisks on demand rather than statically allocating
> them).

Yes, I realized that, once I understood what it was doing. I'm amused by
this, as I had already attacked the problem from another angle: modifying
the rd driver so that if a block is written that is completely zeroed, the
memory is released. (The change to rd is trivial and of reasonable
efficiency, if not astoundingly so.) Of course, this only produces useful
results if ext2 zeros all deleted blocks, which it doesn't, _especially_
the bforgotten blocks. :-)

However, this reclamation is only used by ext2fs, and only by the truncate
call. I'm not positive whether files are "truncated" before being deleted.
(If so, deleted files will be reclaimed, but still only in the ext2 fs.)

Obviously, a decent tmpfs would almost certainly be a better approach then
this ext2-on-rd approach.

> > As mentioned in my message to Bill on the list, I'm trying to keep the
> > thing at below-maximum memory usage, so the normal out-of-memory
> > procedures aren't an issue, and a RAM disk is about the only block device
> > in the system, so some other issues aren't important here.
>
> In which case it's very much a specialist application.

A charming way of putting it.

> The whole linux VM is designed around adaptive use of memory. In your
> specific case, then I think that re#defining bforget to simply call
> brelse is probably a reasonable thing to do. If you are asking whether
> bforget has any side effects which will break if we only call brelse,
> then the answer is definitely no: brelse will do just fine in this case.

Thanks, that is what I was hoping for. One quick patch later, and
everything seems stable, including buffer usage (which is now rock solid.)

Thanks for the assistance!

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)



-
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

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans