Technical data

System Management Features
4.10 OpenVMS SMP Performance Improvements (Alpha)
must be placed into a mutex wait state or when mutex waiters must wake up,
SCHED will still need to be acquired.
• Improved Process Scheduling
Changes made to the OpenVMS process scheduler reduce contention on the
SCHED spinlock. Prior to OpenVMS Version 7.3, when a process became
computable, the scheduler released all IDLE CPUs to attempt to execute the
process. On NUMA systems, all idle CPUs in the RAD were released. These
idle CPUs competed for the SCHED spinlock, which added to the contention
on the SCHED spinlock. As of OpenVMS Version 7.3, the scheduler only
releases a single CPU. In addition, the scheduler releases high numbered
CPUs first. This has the effect of avoiding scheduling processes on the
primary CPU when possible.
To use the modified scheduler, users must set the system parameter SCH_
CTLFLAGS to 1. This parameter is dynamic.
• Improved SYS$RESCHED
A number of applications and libraries use the SYS$RESCHED system
service, which requests a CPU to reschedule another process. In releases
prior to OpenVMS Version 7.3, this system service would lock the SCHED
spinlock and attempt to reschedule another computable process on the CPU.
Prior to OpenVMS Version 7.3, when heavy contention existed on the SCHED
spinlock, using SYS$RESCHED system increased resources contention. As
of OpenVMS Version 7.3, the SYS$RESCHED system service attempts to
acquire the SCHED spinlock with a NOSPIN routine. Thus, if the SCHED
spinlock is currently locked, this thread will not spin. It will return back to
the caller.
• Lock Manager 2000 and 180 improvements
There are several changes to the lock manager. For OpenVMS Clusters,
the lock manager no longer uses IOLOCK8 for synchronization. It now uses
the LCKMGR spinlock, which allows locking and I/O operations to occur in
parallel.
Remaster operations can be performed much faster now. The remaster
code sends large messages with data from many locks when remastering as
opposed to sending a single lock per message.
The lock manager supports a Dedicated CPU mode. In cases where there is
very heavy contention on the LCKMGR spinlock, dedicating a single CPU to
performing locking operations provides a much more efficient mechanism.
• Enhanced Spinlock Tracing capability
The spinlock trace capability, which first shipped in V7.2-1H1, can now trace
forklocks. In systems with heavy contention on the IOLOCK8 spinlock, much
of the contention occurs in fork threads. Collecting traditional spinlock data
only indicates that the fork dispatcher locked IOLOCK8.
As of OpenVMS Version 7.3, the spinlock trace has a hook in the fork
dispatcher code. This allows the trace to report the routine that is called by
the fork dispatch, which indicates the specific devices that contribute to heavy
IOLOCK8 contention.
• Mailbox driver change
System Management Features 4–13