Date: Wed, 12 Aug 1998 22:09:06 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: bf20761@binghamton.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Some buffer questions Message-ID: <199808130309.WAA07267@dyson.iquest.net> In-Reply-To: <Pine.SOL.L3.93.980812154116.26372B-100000@bingsun1> from zhihuizhang at "Aug 12, 98 04:05:27 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
zhihuizhang said: > > Hi, > > It seems to me that there are two kinds of buffers: phyical buffers and > (normal?) buffers. Both use the structure buf to describe them. Normal > buffers are further divided into VMIO and non-VMIO. Can any one explain > these classifications to me? > I wrote the code, so can be pretty definitive: The "VMIO" buffer cache code (it is a misnomer actually), is meant to try to buffer data with file VM objects as being the memory supply rather than anonymous VM objects. This automatically allows for coherency between mmap and file I/O. The "physical" buffers are mostly temporary kernel mappings with I/O request info. They are segregated from the buffer cache, since they are used for I/O requests that are not buffer cache related. Mostly, they are used for raw disk I/O or certain kinds of VM operations (like swap I/O.) The "VMIO" buffers are buffers with data backed by VM objects. This scheme was chosen to support relatively seamless compatibility with legacy BSD systems. The non-"VMIO" buffers are used when it isn't convienient to use the VMIO scheme, or when there is little to be gained from the coherency. The VMIO scheme works, but is complex for block sizes < PAGE_SIZE. Since directories are usually < PAGE_SIZE, and directory corruption is disasterous, I initially chose not to use a file VM object backing for dirs. Eventually VDIRs should probably be backed the same way as regular files, but it isn't really needed. The buffer cache policy is meant to bias towards keeping non-VM object based buffers longer than VM object based buffers. This is because that VM object based buffered data can persist longer than the buffer itself. (This is one reason for some of the problems with softupdates.) FreeBSD is generally not dependent on the buffer cache for buffering. In fact, the original goal was to use the buffer cache as a temporary I/O mapping and I/O request scheme, and the actual bulk data caching would be in the VM objects. The policies in the buffer cache code are NOT LRU, but are similar to LRU. This can significantly improve performance under load, with almost no light loaded cost. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808130309.WAA07267>