/sys$common/syshlp/SDA.HLB  —  SPL Extension, Overview
    To synchronize access to data structures, the OpenVMS operating
    system uses a set of static and dynamic spinlocks, such as
    IOLOCK8 and SCHED. The operating system acquires a spinlock
    to synchronize data, and at the end of the critical code path
    the spinlock is then released. If a CPU attempts to acquire a
    spinlock while another CPU is holding it, the CPU attempting to
    acquire the spinlock has to spin, waiting until the spinlock is
    released. Any lost CPU cycles within such a spinwait loop are
    charged as MPsynch time.

    By using the MONITOR utility, you can monitor the time in
    process modes, for example, with the command $ MONITOR MODES.
    A high rate of MP synchronization indicates contention for
    spinlocks. However, until the implementation of the Spinlock
    Tracing utility, there was no way to tell which spinlock was
    heavily used, and who was acquiring and releasing the contended
    spinlocks. The Spinlock Tracing utility allows a characterization
    of spinlock usage. It can also collect performance data for a
    given spinlock on a per-CPU basis.

    This tracing ability is built into the system synchronization
    execlet, which contains the spinlock code, and can be enabled
    or disabled while the system is running. There is no need to
    reboot the system to load a separate debug image. The images that
    provide spinlock tracing functionality are as follows:

       SYS$LOADABLE_IMAGES:SPL$DEBUG.EXE
       SYS$SHARE:SPL$SDA.EXE

    The SDA> prompt provides the command interface. From this command
    interface, you can load and unload the spinlock debug execlet
    using SPL LOAD and SPL UNLOAD, and start, stop and display
    spinlock trace data. This allows you to collect spinlock data
    for a given period of time without system interruption. Once
    information is collected, the trace buffer can be deallocated
    and the execlet can be unloaded to free up system resources. The
    spinlock trace buffer is allocated from S2 space and pages are
    taken from the free page list.

    Should the system crash while spinlock tracing is enabled, the
    trace buffer is dumped into the system dump file, and it can
    later be analyzed using the spinlock trace utility. This is very
    useful in tracking down CPUSPINWAIT bugcheck problems.

    Note that by enabling spinlock tracing, there is a performance
    impact. The amount of the impact depends on the amount of
    spinlock usage.
Close Help