Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!mmdf
From: wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu
Newsgroups: comp.os.minix
Subject: Re: Better performance for 68K based minix?
Message-ID: <51531@nigel.ee.udel.edu>
Date: 22 Apr 91 18:16:04 GMT
Sender: mmdf@ee.udel.edu
Lines: 27


Cristoph writes:
>It is totally illegal that FS calls phys-copy.
>...
>FS really is NOT allowed to access anything outside its address space
>since it is a normal process. It has to call a kernel function to
>copy stuff to another process, which might e.g. reside on another
>machine!

	True.  For another performance hack (which I think could be made
"legal"), how about an option to open() which causes FS to not use the
buffer cache on IO to that file.  Have the FS give the address of the user's
buffer to the kernel the same way it does for access to raw disk devices.
This could make a difference with programs which sequentially access lots of
files, i.e.  "tar", and never access that data again.  The difficulty would
be if two programs had the same file open one with caching the other without.
The FS would know about both programs access to the file so it could be made
to handle it, but it would require more extensive changes to the code.

	Of course, if you were too quick to embrace this option, you would
never cache anything which would give you the exact opposite effect.  I
would limit it to "tar, "dd", etc. which know they are going to access lots
of data and could (should) be written to read the data in large chunks.
(This would help to compensate for the potential performance loss that not
using the file cache's read ahead capability would cause.)

				Bill Bogstad