On Wed, 23 Oct 2002, Julian Elischer wrote: > Bill Jolitz had a plan for 386BSD where all the buffers were nearly > always unmapped from KVM. He was going to have a number of slots > available for mapping them which would be used in a lifo order > > The number of slots was going to be somehow tunable > but I don't remember the details.
We essentially have this now. Most disk blocks are cached in physical pages (VMIO pages) and are disassociated from the the buffer cache and not mapped into vm. Some blocks are mapped into buffers. There are a limited number of slots (nbuf). nbuf hasn't grown nearly as fast as disks or main memory, so what was once a large non-unified buffer cache (nbuf * MAXBSIZE worth of caching) is now just a small number of vm mappings (nbuf of them). > When you wanted to access a buffer, it was mapped for you > (unless already mapped).. It would be unmapped when it's slot > was needed for something else. WHen you accessed a buffer already mapped > it would move it back to the top of the list. > Various events could pre-unmap a buffer. e.g. the related vm object was > closed. (0 references). Almost exactly what we have. It turns out to be not very good, at least in its current implementation, since remapping is too expensive. Things work OK to the extent that remapping is not required, but so would a much simpler implementation that uses less vm and more copying of data (copying seems to be faster than remapping). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
