Messages in this thread | | | Date | Fri, 28 Aug 1998 21:09:33 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: 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
| |