On Fri, Jan 29, 2010 at 2:08 PM, Donald Allen <[email protected]> wrote: > On Fri, Jan 29, 2010 at 1:45 PM, Bob Beck <[email protected]> wrote: >> In short, yes and no. >> >> Before you can get a coherent answer to your question, I will ask you "why". >> >> I.E. What are you looking for from a "unified buffer cache" - mmap coherency? >> >> Because things are being worked on, however we just may not be doing >> it the way you are thinking. >> >> So let me be clear - UBC is a particular way of implementing things. >> What "things" are you looking >> for from UBC - because we may already be doing that without UBC. > > 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, 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.
One other thing: I don't pretend to be an expert on this, but I have the impression that without UBC, there is some extra copying under certain circumstances that happens to/from buffer cache and mapped user buffers that represents some additional inefficiency beyond the issue of leaving memory sitting unused when it could help. One can imagine situations where this would matter, but it was not the prime motivation for my original question. /Don > > /Don > >> >> >> 2010/1/29 Bret S. Lambert <[email protected]>: >>> On Fri, Jan 29, 2010 at 11:17:07AM -0500, Donald Allen wrote: >>>> Any developers care to comment on the state of the unified buffer >>>> cache? I did some searching and turned up threads here and there in >>>> the mail archives. It looks like an attempt was made to add it around >>>> 8 years ago, some bad things happened, and the change got backed out. >>>> Looking at the code, it looks like there is some conditional ubc code >>>> that appears not to be included in the current release. Have I got >>>> this right -- OpenBSD doesn't provide a unified buffer cache at this >>>> time? >>> >>> There is no spoon. >>> >>>> >>>> /Don Allen
