On Mon, 17 Mar 2003, Jason R Thorpe wrote:

> On Mon, Mar 17, 2003 at 04:23:46PM +0100, Johnny Billquist wrote:
> 
>  > Like I said, I haven't really checked anything up, it's just some
>  > semi-unqualified guessing.
>  > 
>  > Since you probably know for sure, you might as well settle this once and
>  > for all. Is the file caching totally zero-copy stuff?
> 
> Right, the data is DMA'd directly into the cache page if the controller
> can do DMA.

Hmmm, maybe I didn't express myself that good.
Of course data is DMAs directly into the cache page.
What I was wondering was when you have a cache hit. The read don't
generate a controller action, and no DMA activity occurs. Do we have the
same amount of memory copying as if we have a cache miss then there isn't
much to argue about.

> Note that in UBC, the cache isn't something bolted onto the side; it's
> fundamentally a part of how all file I/O works.

Yes. But my concern is how the data might be moved around when already in
memory.

But I think I understand how you mean, and if so, the CPU time goes
somewhere else.

>  > If so, do you have any other good ideas why I see peaks of over 70% system
>  > time when running build.sh. (And this is not when running gcc).
> 
> You could be paging a lot; see my comment about bad defaults on small-memory
> machines.  Search the mailing list archives for a post from Simon Burge
> on the subject.

Nope. Lots of memory. The machine have 52 megs. The file cache is
somewhere between 10 and 20 megs (as told by top). Free is around 10 meg.

Heck, it's a 8650, didn't I say so? Not a small machine by any
standards... :-) :-)
(Well, maybe CPU speed by todays measure. Checked dhrystone2, and it
measures to about 10,000 dhrystones. My PII/400 weights in at about
800,000).

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol