I recently asked how SunOS handles its filesystem buffer cache.
(I asked this question because we are doing some NFS performance testing
between systems from several vendors, and I wanted to know how big a file
I'd have to read thru memory on each test run to make sure the file I
was using for testing, had been flushed from the cache.)
The majority of responses I received indicated that SunOS since 4.0
makes all of physical memory (excepting kernel space, of course)
available for pages of executables or files. A file open causes a file
to get memory-mapped into your virtual address space, and reads of the
file result in pages being faulted in. In other words, cached files
compete with programs for pages.
Before 4.0, SunOS did have a filesystem cache which was a fixed percentage
of physical memory, similar to systems like Ultrix and AIX.
Two respondents mentioned that they thought SunOS 4.* had a firewall
preventing filesystem caching from consuming more than a fixed percentage
of pages, but respondents who work at Sun did not mention this, so it
appears that is not the case.
The advantage of this scheme for data-intensive applications is obvious.
The downside is that large amounts of cached filesystem data can cause
poor/erratic interactive response, esp. in small memory configurations. Of
course, with all those cached files it's not always easy to figure out whether
your system would significantly benefit from more real memory.
The name of one author, and two titles of papers that were presented at
USENIX conferences in the 85-87 timeframe, were mentioned:
"The SunOS Virtual Memory System|Implementation"
"Virtual Memory Architecture in SunOS"
Thanks to the following persons for their responses:
firstname.lastname@example.org (Mahesh Subramanya)
Aydin Edguer <email@example.com>
"Anthony A. Datri" <firstname.lastname@example.org>
stern@sunne.East.Sun.COM (Hal Stern - Consultant)
tgsmith@East.Sun.COM (Timothy G. Smith - Technical Consultant Sun Baltimore)
wolfi@Germany.Sun.COM (Wolfgang Thaler - Sun Germany National Support Engineer - Munich)
Tim Becker <email@example.com>
steve@umiacs.UMD.EDU (Steve D. Miller)
firstname.lastname@example.org (Frank Greco)
swc%newton.UVM.EDU@griffin.UVM.EDU (Steve Chappelow)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:10 CDT