Uniprocessor (UP) Emulation and Driver Binding is required
to properly execute non-multithreaded drivers and other non-threaded
kernel functionality on a symmetric multiprocessing (SMP) system.
The current HP-UX Uniprocessor Emulation and Driver Binding is implemented
through a combination of the up_io_sema
and the spl_lock. These are both
global locks with high contention rates. To meet scalability requirements
for upcoming platforms, HP will be removing the spl_lock
and replacing the up_io_sema with
a binding mechanism. This design is a shift towards a multiprocessor
(MP) centered design which will no longer stall out MP processing
to accommodate uniprocessor (UP) modules. If the performance impact
incurred by a UP module as a result of this model shift is determined
to be unacceptable, then that module should be made MP-SAFE.
Impact |
 |
There are no driver or module changes required as a result
of implementing this new model. The changes required to implement
this feature are contained within what would typically be considered
the kernel framework or infrastructure.
The design being implemented will bind the uniprocessor driver/module
to a single processor, eliminating the need for the up_io_sema/spl_lock
combination. In addition to the global lock removal, the overhead
associated with checking for a uniprocessor module will be removed
from the primary code path. A secondary advantage to the design
will be the simplification of the spl code path.
The binding mechanism is being leveraged from existing interfaces
put in place for processor affinity. The processor affinity interface
will be extended to introduce binding functionality. The streams
subsystem will be modified to place binding calls instead of acquiring
the up_io_sema, and a new callout interface will be created to address
streams requirements. To enhance the callout processing and facilitate
the design of the new callout interface, per-processor callouts
will be introduced.
The existing uniprocessor specific message passing infrastructure
will have to be modified to support message forwarding. This code
path will be modified to ensure that messages destined for uniprocessor
modules will be forwarded to the correct processor in the correct
order.
The only user level visable manifestation of this change will
be the possibility of a mpctl() system call failing
an affinity request due to bound driver requirements. This will
only occur if the user specified a mandatory binding. If an advisory
binding was requested the affinity will be overtaken if necessary.
Printable version
