A patch was recently submitted to the OpenBSD -misc mailing list introducing a Unified Buffer Cache (UBC). The patch is currently only for the i386 and is the beginning of a port from the NetBSD UBC code. Ted, the author, tagged on the following disclaimer, "I did this mainly for self-interest, and because I want UBC and I want it now. :). Since it's done, I figured I could share, but don't think that the OpenBSD developers have anything to do with this." That said, Ted has noticed a performance boost with his patch.
Learn more about NetBSD's UBC implementation (which the above patch is based upon) in this interesting USENIX paper titled, UBC: An Efficient Unified I/O and Memory Caching Subsystem for NetBSD. The paper explains, "Modern operating systems allow filesystem data to be accessed using two mechanisms: memory mapping, and I/O system calls such as read() and write(). In traditional UNIX-like operating systems, memory mapping requests are handled by the virtual memory subsystem while I/O calls are handled by the I/O subsystem. Traditionally these two subsystems were developed separately and were not tightly integrated." The aim of Ted's patch is to integrate these two subsystems.
I've created my own UBC (unified buffer cache) patch. I expect it's not
perfect, but seems to be working for me. Instead of using the UBC
branch, I took the original UBC import and rolled it forward to today's
current. Patch applies against today's cvs co -rHEAD.
pros:
1. faster. compiling a kernel:
UBC : 517.178u 41.811s 9:58.91 93.3% 0+0k 121+615io 129pf+0w
current : 522.022u 40.335s 10:15.73 91.3% 0+0k 5877+12957io 729pf+0w
compiling is hardly disk bound. expect a bigger boost for apps that
have a large disk working set. 2. OpenBSD is essentially the last OS
that lacks a variable sized disk cache. This brings us in line.
cons:
1. I haven't fully tested it, and it's not even close to being synced
with NetBSD yet. Also some parts, such as NFS, aren't included. 2.
Even current NetBSD has some problems were the buffer cache can grow out
of control and evict pages from the programs you're using.
The patch is only for i386 right now. The changes for sparc and other
archs were fairly complicated and I can't test them, and it probably
doesn't matter much for 95% of you. It also, as noted, doesn't fix up
NFS, which I'm not using and is large and complicated. It will wait for
a later day. I patched miscfs/*, msdosfs, and ufs/*. I don't really
have the means of doing strenuous testing. I do know that it will fall
over if you run out of memory, but stock OpenBSD has the same problem.
I can use it for all the same tasks I typically use my system, and it's
prefectly fine, though.
Get it at http://www.zeitbombe.org/ubc.diff.gz
The diff is large. 26000 lines, split 50/50 between UVM and rest of
kernel. 200K compressed. The kernel configuration I used for testing is
in the patch, though you'll almost certainly need to edit it.
DISCLAIMER: I did this mainly for self-interest, and because I want UBC
and I want it now. :). Since it's done, I figured I could share, but
don't think that the OpenBSD developers have anything to do with this.
(Other than the fact that they wrote OpenBSD of course.) It is not
"officially licensed."
From here, I'm going to fix NFS too, and then start pulling in more of
the NetBSD changes. If others are interested in working on an
unofficial UBC project, maybe we could put something together.
ted
From: tedu
Subject: Re: UBC patch
Date: Sat, 6 Jul 2002 21:59:40 +0000
For your further pleasure, you can get a patch which updates top so you
can see the buffer cache in action.
http://www.zeitbombe.org/top.diff
--
Don't be humble; you're not that great.
Freebsd has had this for year
Freebsd has had this for years.
Info
Linux
Does Linux have a similar system, if not.... /me wants one like a child wants candy, because speed == good :)
re: Linux
According to this article a unified buffer cache was introduced to Linux with kernel 2.4.10, the one where the -aa VM replaced the rmap VM.
According to the UBC paper, L
According to the UBC paper, Linux 2.2 has a very similar system, but very bad IDE drivers. I'd be curious to see benchmarks like those in the paper for Linux 2.5 and {Free,Net,Open}BSD-current.