Glen Lalonde <lalonde@torolab2.vnet.ibm.com> (04/22/91)
I found a message from way back in 89 about how to patch FS to call phys_copy directly thus you don't need to send/rec a message from the kernel to do the copy. Later the person indicated this patch did not work because the process may be shadowed. So I went about doing the same type of thing but this time with a fix to the shadow problem. FS gets informed when a fork happened, thus it knows which processes are shadowed. All you need to do is tell it when a exec occures. I modified the fproc table in fs to have an entry which indicates the process may be shadowed. In the fork processing of FS I set the bit true for the child and father. And now I have MM send a message to FS telling it when/who did a exec. At which point FS reset the bit in the fproc table. This does work in most cases, but not for the shell since it forks, child execs. Which will have the child set to no shadow but not the shell. No big deal most processes fork/exec. Anyways, what I do in FS rw_user is check the bit and call phys_copy if I know the process is not shadowed. This will reduce the number of messages by 2, from 4 or 6. See page 184 of the book. I did hope for a 5-15% decrease in time for reads/writes. I tried to measure the decrease by using about 10 lines of dd if=/dev/ram of=/dev/null bs=1024 count=500, in a shell then doing 'time' on the shell. What this showed was a decrease in user time from 8.0 to 4.5 BUT an increase in sys time from 1:18.0 to 1:21.0 or so. I really don't understand this, the copy is done in FS not kernel but both get rolled up in sys time.(correct?) Thus why the change? Is there a better way to measure this? BTW, real time was constant over the two cases both giving about 1:26.0 I am using MacMinix with a GCC compiled mm and fs.
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/22/91)
It is totally illegal that FS calls phys-copy. This works (INCIDENTALLY) on the Mac, ST, and AMIGA since they have no MMU and memory protection hardware. 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! C.v.W.
Tyler Sarna <tsarna@polar.bowdoin.edu> (04/22/91)
In comp.os.minix, Christoph van Wuellen <HBO043%DJUKFA11.BITNET%CUNYVM.CUNY.EDU@VM1.NoDak.EDU> writes: > It is totally illegal that FS calls phys-copy. > This works (INCIDENTALLY) on the Mac, ST, and AMIGA since they have > no MMU and memory protection hardware. This isn't strictly true. Many Amiga's and Mac's have MMU's, and apparently the new Atari machine (being 030-based) does too. It isn't that they don't have them, they just aren't currently used under Minix. Someone may well use the MMU some day, either for complete VM, just for memory protection, instead of shadowing, or to simply remap memory above 0x00FFFFFF so that Minix can use it (sizeof(foo *) == 4 means a pointer is 4 bytes, darnit. If only three were needed, sizeof would be three. Why do otherwise highly intelligent people insist on storing extra garbage in pointers?!?! There are these neat little things called "structures" or "records", which were designed just for things like this.) > 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! Or more likely, "which might be at a virtual != physical address". -- Tyler "Ty" Sarna tsarna@polar.bowdoin.edu "My hair does not require trimming, you lunkhead." - Data
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/23/91)
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
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (04/23/91)
This hack is again illegal. It is restricted to applications which only do I/O in multiples of the disk sector size. If you read, e.g. 1 byte from a disk file, you actually read a whole block, and this has to be buffered somewhere. C.v.W.
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/24/91)
C.v.W. says: >This hack is again illegal. [refering to my suggestion to allow non buffer cached file IO] >It is restricted to applications which only do I/O in multiples of >the disk sector size. >If you read, e.g. 1 byte from a disk file, you actually read a whole >block, and this has to be buffered somewhere. Oops... You're right. You would have to restrict IO in the same way that IO to the raw disk is restricted. Hmmm, you would also have to ignore any excess data in the partial block at the end of the file. Any programs that used this "hack" would have to be taught to stat() the file and only use that many bytes. Of course, this would cause even more problems with files that were actively being written too while being read unbuffered. Could still be done, but it is becoming less and less attractive. Forget I ever mentioned it... Bill Bogstad