Jonathan Stone said:
> 
> John,
> 
> Thanks for the several clarifications to Simon Burge and myself.
> While this definitely not my area of research interest, I appreciate
> the numbers even more with the extra details about exactly what is
> being measured.
> 
> Some of the questions which could easily be misunderstood as hostile
> disbeleif, rather than trying to understand precisely what was being
> reported.  Thanks especially for answering those factually.
> 
> (Yes, btw, I knew the merged buffer cache goes back some years, but as
> you know, that wasnt really the point of my analogy. Other changes
> matter, too:).
> 
> I havent tried it personally, but several of my coulleages in the DSG
> research group here have toyed with tuning Linux compilation. They
> find that when the total of GCC's code and data, plus the source code,
> exceeds total RAM, then the machine thrashes.  I've seen a seen
> similar phenomenon with older SunOS versions (4.1.1 through 4.1.3.  or
> thereabouts). I dont know for sure, but I'd conjecture the split
> buffer cache/VM might do better than a unified one under these
> conditions.   All food for thought.
> 
I agree about the Linux thrashing, and you are seeing one of the
MAJOR reasons why FreeBSD beats Linux under load.  The buffer
cache policy on Linux (or whatever) is totally wrong.  I decided
NOT to punt on a merged cache, and figure out what was wrong
with broken buffer cache policies in SVR4, for example.  Splitting
the cache throws the baby out with the bath water, and only covers
up the real problem.  (Splitting the cache becomes a tuning issue,
that the OS should really handle.)

Thingk of the goal function: minimize I/O.  The goal function
of "caching" is orthgonal to what you want.  When optimizing caching,
does one mean, cache data, or cache program or both or how much?

Solving the problem by splitting it only enforces an artficcial
barrier.  Such an artificial barrier makes caching of one type of
data or another less than optimal.  However, an incorrect policy
leads to thrashing as on SVR4 or Linux.  We have gone about as
far as reasonable on FreeBSD, and that is kind-of only one issue
that we have satisfactority worked.

There is alot of work in FreeBSD dealing with these policy issues,
and is one reason why FreeBSD does work well under load.  The end
conditions are very important, and are part of the reason for
the lousy perception that poeple have for NT.


-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.