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