On Fri, Jan 29, 2010 at 01:24:38PM -0700, Bob Beck wrote: > > My question was motivated by noticing that repeated accesses to a > > fairly large file (~ .75 Gb) during a debugging session were slow. It > > seemed like the system was re-reading the file from the disk when it > > felt like it ought to be sitting in the buffer cache. A little > > experimenting with vmstat running confirmed this. I then tried the > > same experiments with a Linux system running on comparable hardware > > (same amount of memory -- 2 Gb) and got the caching behavior I > > expected. > > So what you are asking for is a bigger buffer cache, not "ubc"
Well, to be fair, he was asking for $buzzword. So we could load him up with some Customer-Facing Enterprise Extranet Bundles, served over XML in a proactive win-win paradigm. Then his disk reads would be all like "zoom!!!" Or, for brevity's sake: there is no spoon. > > 1) install current > 2) sysctl -w kern.bufcachepercent=90 > > report any issues back to me and this list. > > done. > > > > > So, to answer your question, I want to be able to be able to use the > > hardware resources available efficiently in situations like this, > > rather than having a lot of memory go unused that could otherwise > > prevent the system from keeping me waiting. If good adaptive behavior > > can be built into the OS to move the boundary between page frames and > > buffer cache ?(and I'm well aware that these sorts of heuristics can > > work well in some situations and bite you in the ass in others), then > > that would be wonderful. But if it can't, then I'd be happy to have a > > knob to turn, which I *think* is what you are working on. I do know > > that NetBSD, FreeBSD and Linux all have implementations of the UBC > > idea -- how well they work is another matter. > > > > At this point, I don't have a particular concern about mmap coherence. > > > > Some do, art@ has been looking at it and may eventually get that working well.
