From owner-freebsd-hackers Wed Aug 12 20:09:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28275 for freebsd-hackers-outgoing; Wed, 12 Aug 1998 20:09:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28255 for ; Wed, 12 Aug 1998 20:09:38 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id WAA07267; Wed, 12 Aug 1998 22:09:06 -0500 (EST) (envelope-from toor) Message-Id: <199808130309.WAA07267@dyson.iquest.net> Subject: Re: Some buffer questions In-Reply-To: from zhihuizhang at "Aug 12, 98 04:05:27 pm" To: bf20761@binghamton.edu Date: Wed, 12 Aug 1998 22:09:06 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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