This is a major revamping of our MSFBUF API. MSFBUFs are used to map
authorMatthew Dillon <dillon@dragonflybsd.org>
Fri, 4 Mar 2005 00:44:49 +0000 (00:44 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Fri, 4 Mar 2005 00:44:49 +0000 (00:44 +0000)
commita5d36a1d7a21c27106a36374a20c477bbc7b4801
tree4493d3e9143349d2c10356ab71a72a7ebca76de9
parent688862d043576d3fa7e39a3810e1a8627bf84626
This is a major revamping of our MSFBUF API.  MSFBUFs are used to map
things into kernel memory so the kernel and device drivers which require
such mappings can easily get them.  MSFBUFs will soon replace the buffer
cache's KVA mapping code, be used in the journaling code, get and put pages,
reverse-map local kernel buffers, as well as other things.

The eventual goal is to make KVA mappings completely optional and pass
XIOs down the I/O chain, and if a device driver needs a mapping it would
then be able to use an MSFBUF to get it.  This in turn will allow the
buffer cache to manage much larger data sets and remove the absurdly low
dirty data buffer limitations we currently have.

* Replace the hash table with a simple hint in the vm_page structure.
  Currently we do not avoid the overhead of populating an XIO structure or
  regenerating the page list, but the use of qenter2 does avoid the invltlb
  overhead.  The API and internal structure is designed to allow far better
  optimizations of XIO mappings in the future.

* Remove MSFBUF sharing.  Sharing does not occur very often and not doing
  it allows an msfbuf to inherit certain context-sensitive information
  such as a supplied XIO pointer, cpu affinity (for NUMA), easier SMP
  operation, etc.

* Take advantage of the recent XIO changes.

* Add API routines to generate MSFBUFs from various sources, including
  page lists, XIO's, user bufs, kernel bufs, and soon UIO's.

Submitted-by: Collaboration between Hiten Pandya and Matt Dillon
sys/kern/kern_msfbuf.c
sys/sys/msfbuf.h
sys/vfs/nfs/nfs_bio.c
sys/vm/vm_page.h