lkml.org 
[lkml]   [1998]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Questions: bforget & forgotten pages
    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

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:2.246 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site