Date: Tue, 5 Jan 1999 03:38:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901050338.UAA03450@usr05.primenet.com> In-Reply-To: <199812232324.SAA26271@y.dyson.net> from "John S. Dyson" at Dec 23, 98 06:24:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Almost any negative allegations as to portability regarding the FreeBSD > VM are incorrect and mostly spin. There are features in the FreeBSD VM that > take advantage of CPU capabilities that are inherently non-portable. However, > those features are optional, and not necessary for correct operation. I > suspect that as the Alpha platform is optimized, the VM code will be tuned > to support that super-well also. I have to say that John is right; I ported the FreeBSD VM system to the PPC 603 at one point in time (he's also right about the other faults interrupting, since part of the page stuff has to be done in software there -- same issue with MIPS). The biggest problem I had was the thing was moving too fast for me to be able to track it adequately. That was probably just me (or maybe a lack of documentation describing the thing... ;-)). > Geesh, there is already support in FreeBSD for non-copy read/write to/from > the buffer cache also. It isn't complete, but is there. It only takes > someone to finish the job (which I was in the middle of.) On some machines, > that feature would definitely be a mis-feature, but on the X86, it would > be useful. Yeah, this needs to be finished... > Also, the FreeBSD VFS/VM code already supports the ability to > have non-mapped buffers (and has for 2years.) There is alot in there that > might make the complexity look excessive, but that is only because there > are features in there that are almost ready to go. Actually, I think some of the tighness of VM system integration into the VFS code is a mistake. Specifically, I think that the VM references should be macro-ized so that the underlying VM system has much less impact on the code. I'd like to see VFS modules portable between the BSD's (the main obstacle at this point is that the VM intrusions aren't generalized to ignore the underlying implementation (in the FreeBSD case, the intrusion points for cache coherency have been diked out); after that's fixed, the obstacle becomes the "cookie" crap in VOP_READDIR (it has argument order of operation issues, which is why the NetBSD AFS code won't work in FreeBSD), which should be murdered by splitting the VOP_READDIR into VOP_GETDIRBLK/VOP_GETBLKENTRY to get rid of the need for a cookie for resuming context in a directory block for NFS and too-small-user-buffer based traversals -- at the same time paving the way for kernel based globbing for about a 5 times speed increase for a SAMBA/AFS specific system call KLD module). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901050338.UAA03450>