Chapter 2. SGI SynaptIQ Features

SGI SynaptIQ is an overlay product that adds to or enhances features in base Linux distributions from Red Hat 7.1. The SGI SynaptIQ software provides the Linux kernel version 2.4.2. The following are some of the most significant features that Linux provides:

The SGI SynaptIQ software adds functionality to base Linux distributions that is specific to the SGI Graphics Cluster. This chapter describes the following features:

Patches and Changes to Base Linux Distributions

This section provides an overview of changes that the SGI SynaptIQ software makes in your base Linux distribution.

The following packages were added by SGI:

  • alsa-lib-0.5.10 (ALSA driver libraries)

  • alsa-utils-0.5.10 (ALSA driver utilities)

  • devfsd-2.4.2 (daemon for device file systems)

  • dmapi-0.1.1 (XFS data migration API)

  • hinv-1.4pre2 (hinv command)

  • libdba.so-1.0 (APIs to enhance database performance)

  • lvm-x-1.1 (XFS logical volume manager)

  • mount-2.10f-1.i386 (NFS version 3 mount support)

  • pcp-2.2.0 (Performance Co-Pilot)

  • sard-0.6 (disk activity statistics/analysis)

  • sgi-extra-RedHat-1.8-6 (changed system files for SGI value-added features)

  • sgi-fonts-1.0 (SGI fonts)

  • sgi-initscripts-RedHat-1.7-2 (changed init scripts for SGI value-added features)

  • sgi-logos-1.0.1 (SGI logos)

  • sgi-SynaptIQdocs 1.5 (SGI SynaptIQ documentation)

  • xfsdump-1.0.4 (xfsdump utility)

  • xfsprogs-1.2.0 (XFS program support)

XFS Support

SGI SynaptIQ supports the XFS file system running on Linux platforms. XFS is a scalable, high-performance, journalling file system that SGI has contributed to the Open Source Linux community. The XFS journalling technology lets the file system restart almost immediately after an interrupt, regardless of the number of files it is managing.

XFS is a full 64-bit file system, capable of handling files as large as a million terabytes and of delivering near raw-I/O performance. For information about XFS, see the following:

http://oss.sgi.com/projects/xfs


Kernel-Supported Asynchronous I/O

Kernel-supported asynchronous I/O (KAIO) differs from asynchronous I/O in that it is implemented with support from kernel modifications. These kernel modifications allow KAIO to perform split-phase I/O to maximize concurrency of I/O at a device. Split-phase I/O allows the initiating request (such as an aio_read) to truly queue the I/O at the device as the first phase of the I/O request. The second phase of the I/O request, performed as part of the I/O completion, propagates results of the request. The results may include the contents of the I/O buffer on a read, the number of bytes read or written, and any error status.

For more information about KAIO, see the following URL:

http://oss.sgi.com/projects/kaio


Comprehensive System Accounting (CSA)

CSA is a set of C programs and shell scripts that provide methods for collecting per-process resource usage data, monitoring disk usage, and charging fees to specific login accounts. CSA takes this per-process accounting information and combines it by job identifier (jid) within system boot uptime periods.

CSA provides the following features not available with other Linux accounting packages:

  • User job accounting (ja command), per-job accounting, and daemon accounting

  • Flexible accounting periods (not just daily and monthly periods)

  • Flexible system billing units (SBUs)

  • Offline archiving of accounting data

  • User exits for site specific customization of reports

  • Configurable parameters

For detailed information about CSA, see the following URL:

http://oss.sgi.com/projects/csa


runon Support

SGI SynaptIQ supports the runon command, which runs a command on a particular CPU (this CPU affinity is called process pinning). The runon command can assign process pinning using fork(), or by process ID. Pinning is inherited across fork() and exec() system calls. To change the pinning, you can use the prctl(2) call. The runon(1) man page contains more information.

hinv Support

SGI SynaptIQ supports the hinv command, which displays the contents of the system hardware inventory table. This table is created each time a system is booted and contains entries describing various pieces of hardware in the system. The items in the table include main memory size, cache sizes, floating point unit, and disk drives. Without arguments, the hinv command displays a one line description of each entry in the table. The hinv(1) man page contains more information.

Qualified Drivers

SGI SynaptIQ provides updated drivers, as described in this section.

Advanced Linux Sound Architecture (ALSA) drivers provide advanced multimedia. The asynchronous I/O (AIO) facility implements interfaces defined by capabilities. For more information, see “Advanced Linux Sound Architecture (ALSA) Drivers”.

The QLogic 1080/1280 and 2100 drivers have been supplied by QLogic Corporation, and include updated firmware and improved error handling.

The QLogic drivers were updated to the following new versions:

  • The qla2x00 driver version 4.15 beta for 2100, 2200, and 2300 cards

  • The qla1280 and qla12160 drivers version 3.23 beta

The Alteon Gigabit Ethernet driver has been modified to recognize and drive the SGI Gigabit Ethernet card. SGI SynaptIQ supports version 0.45.

Other drivers were updated to new versions as follows:

  • DAC960 (Mylex) driver version 2.4.10

  • Adaptec driver version 6.1.5


    Note: External storage I/O hardware has been qualified against hardware and software. For information about what has been qualified, see http://support.sgi.com/linux .


Performer for Linux is fully API-compatible with existing Performer applications running on IRIX and is a full distribution, including the core run-time libraries and file loaders, development header files, sample source code, and man pages.

Process Aggregates (PAGG)

Process Aggregates (PAGG) are modifications to the Linux kernel that let developers create loadable kernel modules to group processes into aggregates. PAGG provides functions that allow loadable kernel modules to register as providers of a specific type of process aggregate implementation. Additionally, this feature ensures that membership in a process aggregate, or group, is inherited across process forks.

PAGG can be used to support a formal job container on Linux. To learn more about Process Aggregates and the job container module for Linux, consult the following URL:

http://oss.sgi.com/projects/pagg
 

Comprehensive System Accounting provides enhanced job accounting, which will make use of the job container kernel module. For more information, see “Comprehensive System Accounting (CSA)”, and the following URL:

http://oss.sgi.com/projects/csa


Advanced Linux Sound Architecture (ALSA) Drivers

SGI SynaptIQ contains support for the Advanced Linux Sound Architecture (ALSA) drivers for users who want to use OpenML or who use SGI Graphics Clusters for intensive audio purposes.

ALSA's mixer model provides fine control over muting and volumes of audio channels. Unlike the standard Linux audio drivers (Open Sound System or OSS), ALSA drivers offer a mute separate from volume and distinguish between input gains for recording and output feedback volumes for input sources.

The main advantages of using the ALSA drivers are as follows:

  • Full support for OpenML

  • Advanced multimedia capabilities

  • Audio capabilities essential to professional audio use

  • Advanced synchronization and timing features not available in the standard sound drivers

Performance Co-Pilot

Performance Co-Pilot (PCP) provides a framework and set of services to support system-level performance monitoring and performance management. The PCP open source release provides a unifying abstraction for all of the interesting performance data in a system, and allows client applications to easily retrieve and process any subset of that data using a single API.

A client-server architecture allows multiple clients to monitor the same host and a single client to monitor multiple hosts (for example, in a graphics cluster). This enables centralized monitoring of distributed processing.

Integrated archive logging and replay allow client applications to use the same API to process real-time data from a host or historical data from an archive.

The framework supports APIs and configuration file formats that enable the scope of performance monitoring to be extended at all levels.

The open source release of PCP provides a subset of the features of SGI's Performance Co-Pilot products for IRIX (see http://www.sgi.com/software/co-pilot/ ).

The following is a brief list of PCP features supported in SGI SynaptIQ:

  • The pmsocks utility allows PCP to monitor TCP applications through socks4 firewalls. With this utility, you can monitor systems on the Internet at large from within a firewall.

  • XFS and pagebuf metrics (these are available only if you run XFS).

  • Support for NFS (version 3) PCP metrics.

  • An extension of the weblogs PCP agent lets PCP report proxy HTTP servers and adds assorted HTTP cache statistics.

  • An accounting patch to the kernel (syscall accounting) counts per-CPU system calls, and corresponding new metrics are included in PCP (kernel.all.syscall and kernel.perCPU.syscall). This feature is used by PCP in layered products that integrate with SGI's Embedded Support Partner (ESP) using SGI SynaptIQ as a base.

NFS Enhancements

SGI SynaptIQ includes support for NFS version 3, with some bugfixes included to allow compatibility with IRIX systems.

Large Physical Memory Support

Large amounts of physical memory coupled with the ability to create large (multi-gigabyte) shared memory segments provide a boost in performance to various types of workloads. SGI includes a configuration parameter to configure the Linux community standard implementation—that is, i686 UP and SMP kernels have 4GB memory support (SGI Graphics Cluster Series 12 are limited to 1.5 GB of memory support).

Fast Synchronization Mechanism

While the UNIX System V IPC semaphore facility does provide exceptional capability, its performance leaves much to be desired. Many UNIX vendors have released a low-overhead interapplication synchronization primitive known as “post /wait.”

SGI has included in this release a kernel level implementation of post/wait along with the library containing application APIs. The post allows for a process to “wait” for an event. This event can either be a timeout or a “post” from another process. A group of cooperating processes can use these “post” and “wait” facilities to synchronize among themselves.

In order to use post/wait, the kernel must be compiled with the CONFIG_PW configuration variable, and you may optionally set an additional configuration variable, CONFIG_PW_VMAX. These variables are described in the configuration help. For a user program to use the post/wait facilities, it must link against libdba.so.

For more information on post/wait, please refer to the postwait(3) man page.

POSIX Asynchronous I/O

The ability to overlap I/O and processing activities has always been important to high-performance applications. To allow this type of overlap in single-threaded applications, SGI has included a kernel-level implementation of POSIX asynchronous I/O and the associated API library.

SGI SynaptIQ works with raw devices as well as with file systems including pipes and sockets.

This facility is turned on by setting the CONFIG_AIO kernel option. User code can get access to the facility by linking with libdba.so. Further information can be found in the /lib/libdba/README file.

Kernel Spinlock Metering

SGI SynaptIQ does not include kernel spinlock metering by default, but you can check the following URL for its availability and for additional information:

http://oss.sgi.com/projects/lockmeter

Spinlock metering allows developers to gather statistical information about the SMP kernel's use of spinlocks and mrlocks (multiple-reader single-writer spinlocks). This functionality is called spinlock metering or lockmetering.

If spinlock metering is available from http://oss.sgi.com/projects/lockmeter , it can be built into the kernel using the CONFIG_LOCKMETER configuration option (in the Kernel Hacking section of make xconfig). A kernel built with lockmetering will exhibit a small (roughly 1%) performance degradation relative to a kernel that is not configured for lockmetering.

Crash Functionality

Changes have been made to the Linux crash utility, which are explained briefly below. SGI SynaptIQ uses version 3.1.1, which supports lcrash on IDE drives as well as SCSI drives. General information about lcrash can be found in the /cmd/lcrash/README file. Major changes follow:

  • Linux kernel crash dump enhancements. SGI SynaptIQ provides a configuration option to allow kernel crash dumps to be available. This option is configured to be on by default, and the default dump space is the first swap partition found when booting. If you are building a new kernel, you can specify Support kernel crash dump capabilities in the Kernel Hacking section of make xconfig.

    The crash dump capabilities in the kernel allow the system to create a crash dump when a failure occurs due to a panic() call or an exception. For more details on the dump method, compression used, and so on, please read the LKCD FAQ at the following URL:

    http://oss.sgi.com/projects/lkcd/faq.html
    
    

    Information about LKCD is also available in the file /cmd/lcrash/README.lkcd.

  • Boot up process changes. As the system boots up, the /sbin/vmdump script will be run out of /etc/rc.d/rc.sysinit. This script saves crash dumps and reads sysconfig variables to open the dump device and configure the system for crash dumps.

  • Crash dump configuration options. There are a number of configurable options to save system crash dumps. Please read /etc/sysconfig/vmdump for more details on the options available. The following list describes what the options allow you to do:

    • Determine if you want to implement crash dumps in the kernel

    • Choose whether to save crash dumps to disk or not

    • Change the location to which the crash dumps are saved

    • Specify any block dump device you want

    • Compress (or not compress) the crash dumps

    • Configure the system to reset (or not reset) after a failure

  • The lcrash utility uses the new librl library for command-line input.

Patches, Configuration Options, Commands, and Libraries

The following list describes patches that have been implemented as well as enhancements to configuration options, commands, and libraries:

  • librl library. This new library supplies command line editing and command history functionality. See the /cmd/lcrash/lib/librl/README file for information on how to use this library. The lcrash command uses this library.

  • SMP PTE patch. In stock Linux, the page stealing code that is used under high memory load has a bug that might cause it to steal a page from a process without writing out the contents to swap if the page has been modified by the process. This bug is only present in a multiprocessor machine. SGI SynaptIQ provides a fix for this bug.