> > One of the problems that would make it sensible to do a complete rewrite > of vfs_bio.c is this? > Specifically for that reason, probably not. However, if the effort was taken as an entire and encompassing effort, with the understanding of what is really happening in the code regarding policy (and there is alot more than the original vfs_bio type things), then it would certainly be best. Note that some of the policy might even be marginalized given a restructuring by eliminating the conventional struct buf's for everything except for I/O. In the case of I/O, it would be good to talk to those who work on block drivers, and collect info on what they need. The new definition could replace the struct bufs for the block I/O subsystems, but in many ways could be similar to struct bufs (for backwards compat.)
In the current vfs_bio, the continual remapping is problematical, and was one of the very negative side-effects of the backwards compatibility choice. The original vfs_bio merged cache design actually (mostly) eliminated the struct bufs for the buffer cache interfacing, and the temporary mappings thrashed much less often. It would also be good to design in the ability to use physical addressing (for those architectures that don't incur significant additional cost for physically mapping all of memory.) Along with proper design, the fully mapped physical memory would eliminate the need for remapping entirely. Uiomove in this case wouldn't need virtually mapped I/O buffers, and this would be ideal. However, it is unlikely that X86 machines would ever support this option. PPC's, RXXXX(X) and Alpha can support mapping all of memory by their various means though. In a sense, the deadlock issue is an example of the initially unforseen problems when hacking on that part of the code. I suggest a carefully orchestrated and organized migration towards the more efficient and perhaps architecturally cleaner approach. The deadlock was an after the fact bug that we found very early on, and there was a "temporary" fix for part of it, and a mitigation of the other part. Issues like that can be very, very nasty to deal with. John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
