VMS Help V73 Features, System Management Features, SMP Performance Improvements (Alpha)  *Conan The Librarian (sorry for the slow response - running on an old VAX)

    OpenVMS Alpha Version 7.3 contains software changes that improve
    SMP scaling. Designed for applications running on the new
    AlphaServer GS-series systems, many of these improvements will
    benefit all customer applications. The OpenVMS SMP performance
    improvements in Version 7.3 include the following:

    o  Improved MUTEX Acquisition

       Mutexes are used for synchronization of numerous events on
       OpenVMS. The most common use of a mutex is for synchronization
       of the logical names database and I/O base. In releases prior
       to OpenVMS Alpha Version 7.3, the manipulation of a mutex
       was completed with the SCHED spinlock held. Because the SCHED
       spinlock is a heavily used spinlock with high contention on
       large SMP systems and only a single CPU could manipulate a
       mutex, bottlenecks often occurred.

       OpenVMS Alpha Version 7.3 changes the way mutexes are
       manipulated. The mutex itself is now manipulated with atomic
       instructions. Thus multiple CPUs manipulate different mutexes
       in parallel. In most cases, the need to acquire the SCHED
       spinlock has been avoided. In cases where a process must be
       placed into a mutex wait state or when mutex waiters must wake
       up, SCHED will still need to be acquired.

    o  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.

    o  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.

    o  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.

    o  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.

    o  Mailbox driver change

       Prior to OpenVMS Version 7.3, the mailbox driver FDT routines
       called a routine that locked the MAILBOX spinlock and
       delivered any required attention ASTs. In most cases, this
       routine did not require any attention ASTs to be delivered.
       Because the OpenVMS code that makes these calls already has
       the MAILBOX spinlock locked, the spinlock acquisition was also
       an unneeded second acquire of the spinlock.

       As of OpenVMS Version 7.3, OpenVMS now first checks to see
       if any ASTs may need to be delivered prior to calling the
       routine. This avoids both the call overhead and the overhead
       of relocking the MAILBOX spinlock that was already owned.