How does disk caching work?

"Igor Shmukler" shmukler at mail.ru
Fri Apr 16 15:19:55 PDT 2004


> > > Is there a document anywhere that describes in detail how FreeBSD
> > > handles disk caching? I've read Matt Dillon's description of the VM
> > > system, but it deals mostly with programs, other than vague statements
> > > such as 'FreeBSD uses all available memory for disk caching'.
> > 
> > Well, the statement is not vague. FreeBSD has a unified buffer cache. This means that ALL AVAILABLE 
> > MEMORY IS A BUFFER CACHE for all device IO.
> > 
> > > I think I know how caching memory mapped IO works for the most part,
> > > since it should be treated just like program data, but what about files
> > > that aren't memory mapped? What impact is there as pages move from
> > > active to inactive to cache to free? What role do wired and buffer pages
> > > play?
> > 
> > If file is not memory mapped it is not in memory, is it? Where do you cache it? Maybe I am missing 
> > somewhing? Do you maybe want to know about node caching?
> 
> What if the file isn't memory mapped? You can access a file without
> mapping it into memory, right?

Read/write/execute require mmap as far as I know. What type of access do you want to perform without the mmap?

Not that you asked, but I strongly suggest reading AST's book than Design of 44BSD.

> > When pages are rotated from active to inactive and then to cache buckets they is still retains vnode 
> > references. Once it is in free queue, there is no way to put it back to cache. Association is lost.
> > 
> > Wired pages are to pin memory. So that we do not get situation when fault handling code is paged out.
> > 
> > I am not FreeBSD guru so I never heard of BUFFER pages. Is there such a concept?
> 
> I'm reffering to the 'Buf' column at the top of top. I remember reading
> something about that being used to cache file descriptors before the
> files are mapped into memory, but I'm not very clear on what is actually
> happening.

Ok, I thought that there was an unknown concept of buffer pages. :)


More information about the freebsd-performance mailing list