Subject: Re: FreeBSD Bus DMA
To: None <>
From: Perry E. Metzger <>
List: tech-kern
Date: 06/12/1998 01:04:40
"John S. Dyson" writes:
> > That just isn't possible. Not only have my own experiences not backed
> > this up, but even based on an intellectual examination of the problem
> > it isn't possible. Your drivers don't perform three times faster, and
> > most of the non-i/o bound work in compiling a program doesn't even run 
> > in the kernel. We run the SAME FFS code, so file system performance
> > couldn't produce such a change.
> >
> Well, I am very glad that you have made the statement "That just
> isn't possible".  Think disk cache (and that is only one aspect
> of the difference.)

Sorry, but that hog won't sing. Disk cache only helps you if you're
reading the same data repeatedly. If you're compiling a large source
tree, most of the data you're operating on isn't going to be in cache.

I've actually DONE the test. I invite anyone who wants to to try it
themselves. Take a large source code corpus -- XEmacs isn't a bad
example -- and build it on both systems. Measure the elapsed time. You 
will note that there is no significant difference.

> Are you so blind as to not know that FreeBSD has a fully merged
> cache not dependent on the lame buffer cache scheme?

Show me the numbers. I'll admit we have less than an optimal cache,
but it doesn't make a practical difference in performance of this sort.

> Don't you have clue that our buffer mgmt policy isn't the
> broken and useless sibling of "clock": LRU???

You claim that compiling on your system is much faster (you seem to be 
trying to back away from the "3X" claim). However, buffer management
isn't going to help you when compiling -- your compiler is going to be 
resident no matter what, and your data is going to need to be read off 
the disk no matter what. The real world numbers pretty much bear this
out -- as I noted, I have never found a significant difference in
compile times between the systems.

> When compiling on
> FreeBSD, properly set up, the disk falls silent, and all of the
> memory is working for you.

That isn't possible, period, ever. Unless you've replaced your whole
disk with RAM, you're going to have to bring the source code you are
compiling in to memory at least once, and you are going to have to
spit the results out onto the drive at least once. You can't get
around that.

> I love those old OSes that go chatter-chatter-chatter trying to
> grab header files over and over again.  They are so "retro".

Mine doesn't go "chatter chatter" much either.

> > Extraordinary claims require extraordinary evidence. Your claims
> > demand a reproduceable measurement of some sort. I invite you to
> > present it. The statement "I don't do benchmarks" won't cut it --
> > you've made a remark that is sufficiently extreme that you have an
> > obligation to demonstrate it or withdraw it.
> I cannot withdraw it, simply because it would be lie to do so.

But you refuse to present the proof that would demonstrate it?