Return to uvm_hotplug.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / features

Add an FAQ about uvm_hotplug(9)

    1: # [[!template id=man name=uvm_hotplug section=9]] port-masters' FAQ.
    2: 
    3: 1. Why does it matter?
    4: 
    5: As a port maintainer any architecture that needs to use the virtual memory
    6: sub-system of NetBSD aka uvm is affected by the
    7: [[!template id=man name=uvm_hotplug section=9]] change.
    8: 
    9: Early boot code of every port is affected. Global variables:
   10: struct vm_physseg vm_physmem;
   11: int vm_nphysmem;
   12: are no longer visible. They need to be replaced by appropriate
   13: accessor calls in [[!template id=man name=uvm_hotplug section=9]]
   14: 
   15: These calls are documented as "Utility Functions" in the
   16: [[!template id=man name=uvm_hotplug section=9]] manual.
   17: 
   18: 
   19: The "switchover" CVS commit log is here:
   20: [http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html](http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html)
   21: 
   22: 
   23: 2. What files may be affected?
   24: 
   25: In most of the architectures the "sys/arch/<arch_name>/<arch_name>/machdep.c"
   26: and "sys/arch/<arch_name>/<arch_name>/pmap.c" if they exist are usually
   27: affected.
   28: 
   29: But this may not be a exhaustive list. Any other files that deals with pmap and
   30: stealing pages might also be affected.
   31: 
   32: 3. What does it do ?
   33: 
   34: [[!template id=man name=uvm_hotplug section=9]] manages the previously exposed "vm_physmem" static array which
   35: used to keep track of the memory segments.
   36: 
   37: In the current implementation, the array has been replaced with a
   38: [[!template id=man name=rbtree section=3]] backing which makes the
   39: data structure dynamic.
   40: 
   41: An array based implementation is also provided, for backwards
   42: compatibility. This is the default implementation and does not provide
   43: hot pluggability. It is also used without 'options UVM_HOTPLUG'
   44: However the API itself is implementation agnostic.
   45: 
   46: 4. Why is it needed?
   47: 
   48: With the [[!template id=man name=rbtree section=3]] backing
   49: implementation, the list of physical pages 
   50: in the system is no longer in a static array and can dynamically
   51: expand or collapse, hence adding new pages to the freelist from newly
   52: available RAM / physical memory (plug) or removing retired pages
   53: (unplug) via taking them off the freelist and the old vm_physmem.
   54: 
   55: 5. What should I do?
   56: 
   57: Review the changes to your port due to this new feature. The changes
   58: may have been made without direct knowledge of your port architecture.
   59: 
   60: See if your port has hotpluggable hardware. If it does, write a driver
   61: to use the [[!template id=man name=uvm_hotplug section=9]] api.
   62: 
   63: An example of [[!template id=man name=uvm_hotplug section=9]] api's
   64: application can be found in
   65: [[!template id=man name=balloon section=4]].