Re: Questions: bforget & forgotten pages

Stephen C. Tweedie (sct@redhat.com)
Fri, 28 Aug 1998 21:09:33 +0100


Hi,

On Fri, 28 Aug 1998 09:18:45 -0400 (EDT), Kenneth Albanowski
<kjahds@kjahds.com> said:

> Yes, this looks (to me) like it might make sense, and is the most obvious
> approach. (Though I'd actually prefer _keeping_ the pages as their
> original usage, just to keep buffer usage constant.) But of course the
> page will still "leak" if !!b_count, and I'm still not sure when
> exactly that is expected to occur.

It can happen if some process such as update is currently walking the
buffer list and writing out dirty buffers. The buffer we're about to
forget may be active in that case due to background IO.

> 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).

>> Second, I think you may well have missed the try_to_free_buffer() call
>> from shrink_mmap(). If not, then what exactly is it that you think we
>> should be doing but we're not?

> 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. 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.

Cheers,
Stephen.

-
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