Managing dynamically loadable kernel modules

Automatic unloading

The kernel periodically wakes up the auto-unload daemon to unload any modules that have become candidates for unloading. Modules that were autoloaded become candidates for auto-unloading when they are inactive, they have not been accessed for a predetermined amount of time, and no other loadable modules depend on them.

NOTE: Modules that are demand loaded cannot be auto-unloaded. If a demand loaded module is no longer needed in the system, it must be demand unloaded.

If the attempt to auto-unload a module is successful, the memory allocated for the module is reclaimed. Unloading continues until all the unloadable modules are unloaded. (These unloaded modules remain on the disk, ready to be reloaded whenever necessary.)

For example, a loadable device driver would become a candidate for auto-unloading on the last close of all its configured devices, and a loadable STREAMS module would become a candidate for auto-unloading on its last I_POP. The amount of time that must elapse before inactive modules are considered candidates for auto-unloading is controlled by the value of the global tunable parameter DEF_UNLOAD_DELAY. Individual ``old style'' modules can override the value of the global auto-unload delay by specifying their own value for the auto-unload delay tunable parameter, PREFIX_UNLOAD_DELAY, in their Mtune(DSP) file (but this is not true for ``new style'' modules such as DDI8 device drivers). The name of the module's unload delay tunable must begin with the ``prefix'' field from /etc/conf/mdevice.d/device converted to upper case letters. See Master(DSP) for the structure of the files in mdevice.d.

NOTE: On a demand unload request, the auto-unload delay parameter value is ignored.

Next topic: Demand unloading a DLKM
Previous topic: Unloading modules

© 2007 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 05 June 2007