[BACK]Return to uvm_hotplug.mdwn CVS log [TXT] [DIR] Up to [NetBSD Developer Wiki] / wikisrc / features

Diff for /wikisrc/features/uvm_hotplug.mdwn between versions 1.1 and 1.2

version 1.1, 2016/12/29 16:54:37 version 1.2, 2016/12/29 16:59:58
Line 1 Line 1
 # [[!template id=man name=uvm_hotplug section=9]] port-masters' FAQ.  # [[!template id=man name=uvm_hotplug section=9]] port-masters' FAQ.
   
 1. Why does it matter?    1. Why does it matter?
   
 As a port maintainer any architecture that needs to use the virtual memory       As a port maintainer any architecture that needs to use the virtual memory
 sub-system of NetBSD aka uvm is affected by the       sub-system of NetBSD aka uvm is affected by the
 [[!template id=man name=uvm_hotplug section=9]] change.       [[!template id=man name=uvm_hotplug section=9]] change.
   
 Early boot code of every port is affected. Global variables:       Early boot code of every port is affected. Global variables:
 struct vm_physseg vm_physmem;       struct vm_physseg vm_physmem;
 int vm_nphysmem;       int vm_nphysmem;
 are no longer visible. They need to be replaced by appropriate       are no longer visible. They need to be replaced by appropriate
 accessor calls in [[!template id=man name=uvm_hotplug section=9]]       accessor calls in [[!template id=man name=uvm_hotplug section=9]]
   
 These calls are documented as "Utility Functions" in the       These calls are documented as "Utility Functions" in the
 [[!template id=man name=uvm_hotplug section=9]] manual.       [[!template id=man name=uvm_hotplug section=9]] manual.
   
        The "switchover" CVS commit log is here:
        [http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html](http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html)
   
 The "switchover" CVS commit log is here:    2. What files may be affected?
 [http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html](http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html)  
   
        In most of the architectures the "sys/arch/<arch_name>/<arch_name>/machdep.c"
        and "sys/arch/<arch_name>/<arch_name>/pmap.c" if they exist are usually
        affected.
   
 2. What files may be affected?       But this may not be a exhaustive list. Any other files that deals with pmap and
        stealing pages might also be affected.
   
 In most of the architectures the "sys/arch/<arch_name>/<arch_name>/machdep.c"    3. What does it do ?
 and "sys/arch/<arch_name>/<arch_name>/pmap.c" if they exist are usually  
 affected.  
   
 But this may not be a exhaustive list. Any other files that deals with pmap and       [[!template id=man name=uvm_hotplug section=9]] manages the previously exposed "vm_physmem" static array which
 stealing pages might also be affected.       used to keep track of the memory segments.
   
 3. What does it do ?       In the current implementation, the array has been replaced with a
        [[!template id=man name=rbtree section=3]] backing which makes the
        data structure dynamic.
   
 [[!template id=man name=uvm_hotplug section=9]] manages the previously exposed "vm_physmem" static array which       An array based implementation is also provided, for backwards
 used to keep track of the memory segments.       compatibility. This is the default implementation and does not provide
        hot pluggability. It is also used without 'options UVM_HOTPLUG'
        However the API itself is implementation agnostic.
   
 In the current implementation, the array has been replaced with a    4. Why is it needed?
 [[!template id=man name=rbtree section=3]] backing which makes the  
 data structure dynamic.  
   
 An array based implementation is also provided, for backwards       With the [[!template id=man name=rbtree section=3]] backing
 compatibility. This is the default implementation and does not provide       implementation, the list of physical pages 
 hot pluggability. It is also used without 'options UVM_HOTPLUG'       in the system is no longer in a static array and can dynamically
 However the API itself is implementation agnostic.       expand or collapse, hence adding new pages to the freelist from newly
        available RAM / physical memory (plug) or removing retired pages
        (unplug) via taking them off the freelist and the old vm_physmem.
   
 4. Why is it needed?    5. What should I do?
   
 With the [[!template id=man name=rbtree section=3]] backing       Review the changes to your port due to this new feature. The changes
 implementation, the list of physical pages        may have been made without direct knowledge of your port architecture.
 in the system is no longer in a static array and can dynamically  
 expand or collapse, hence adding new pages to the freelist from newly  
 available RAM / physical memory (plug) or removing retired pages  
 (unplug) via taking them off the freelist and the old vm_physmem.  
   
 5. What should I do?       See if your port has hotpluggable hardware. If it does, write a driver
        to use the [[!template id=man name=uvm_hotplug section=9]] api.
   
 Review the changes to your port due to this new feature. The changes  
 may have been made without direct knowledge of your port architecture.  
   
 See if your port has hotpluggable hardware. If it does, write a driver  
 to use the [[!template id=man name=uvm_hotplug section=9]] api.  
   
 An example of [[!template id=man name=uvm_hotplug section=9]] api's  
 application can be found in  
 [[!template id=man name=balloon section=4]].  
   
        An example of [[!template id=man name=uvm_hotplug section=9]] api's
        application can be found in
        [[!template id=man name=balloon section=4]].
   
Removed from v.1.1  
changed lines
  Added in v.1.2

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb