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

    > First, I'd just keep bforget, but you might think about doing
    > if (!buf->b_count) {
    > remove_from_queues(buf);
    > put_last_free(buf);
    > clear_bit(BH_Touched, &buf->b_state);
    > try_to_free_buffer(buf, &buf, 6);
    > } else
    > refile_buffer(buf);
    > (untested!!) at the end of __bforget. That will attempt to immediately
    > reclaim the buffers after freeing them. If there are any other,
    > non-freeable buffers in the same page, then the forgotten buffer will
    > just be left on the free list but won't be completely deleted.

    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.

    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? Except I get the impression
    that this is not so, due to race conditions...

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

    > > More interestingly, if you repeatedly create and truncate a file,
    > > you'll continually spawn more forgotten buffers.
    > If they have been cleaned and refiled, then they _should_ be reclaimed
    > by the normal mechanisms, but only when the memory is needed for
    > something else. Have you got evidence that this is not happening?

    Not at all, and I really should have put a disclaimer on my message:
    please folks, don't listen to me if you want to hear about kernel bugs, or
    indeed anything whatsoever relating to Linux on a PC. At the moment, I'm
    stretching Linux into some very weird shapes, so anything that breaks is
    my fault.

    Kenneth Albanowski (, CIS: 70705,126)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.022 / U:26.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site