			 Release Notes

     This document summarizes the contents and special instructions for the 
     Tru64 UNIX V5.1B patches contained in this kit.

     For information about installing or removing patches, baselining, 
     and general patch management, see the Patch Kit Installation 
     Instructions document. 

1 Release Notes


This Early Release Patch Kit Distribution contains:

   - fixes that resolve the problem(s) reported in: 
        o 19082 19182 19283 19290 19399 19411 19415 19435 19491 19580 
             * for Tru64 UNIX V5.1B T64V51BB26AS0005-20050502.tar (BL26)

	This kit includes a patch which requires system reboot.

 The patches in this kit are being released early for general customer use.
 Refer to the Release Notes for a summary of each patch and installation 
 prerequisites.

 Patches in this kit are installed by running dupatch from the directory 
 in which the kit was untarred. For example, as root on the target system:

	> mkdir -p /tmp/CSPkit1
	> cd /tmp/CSPkit1
	> <copy the kit to /tmp/CSPkit1>
	> tar -xpvf DUV40D13-C0044900-1285-20000328.tar
	> cd patch_kit
	> ./dupatch

2 Special Instructions

SPECIAL INSTRUCTIONS for Tru64 UNIX V5.1B Patch C1884.00
In the V5.1B-3 release, performance enhancements for NUMA class systems have
been provided through two new tuning options. 

The vm_overflow feature changes how large memory applications "borrow" memory
from other resource affinity domains (RADs) when their local memory resources
are exhausted. This can be used on all NUMA class systems. 

For the ES47, ES80, and GS1280 systems the previously hidden cpus_in_rad
variable can now be set to more than two CPUs; this allows pooling together the
CPU, memory, and I/O resources of a set of CPUs and treating it as a single
resource affinity domain (RAD). Like vm_overflow, this can allow large memory
applications to have access to more memory that is managed as if it were all
physically "local". 

generic: cpus_in_rad

    With the default value of cpus_in_rad (zero) every cpu is in its own
    resource affinity domain. This is equivalent to setting the value to 1. 
    When the value of cpus_in_rad is set larger than 1, certain configuration
    restrictions must be considered:

    1) Values for the cpus_in_rad tunable must be a power of two. 

    2) Take caution setting cpus_in_rad to 64 on a 64 processor system. When
       the number of RADs is decreased by increasing the value of cpus_in_rad,
       the number of per-RAD locks needed to manage resources also decreases.
       This may result in increased lock contention and may result in poor
       performance or system panics. The system automatically adjusts the 
       generic: locktimeout tunable if cpus_in_rad is set to 64 on a 64 
       processor system, but depending on system load it may need to be 
       manually increased to avoid locktimeout panics. The maximum value 
       for locktimeout is 60 seconds. If the value needs to be increased, do
       so in 5 second increments. If the maximum value is reached and the 
       system is unstable, reduce the value of cpus_in_rad and escalate the 
       problem through your support channels.

    3) "Missing" cpus are included in the count of cpus in a rad.

       Consider a system configured with cpus 0,1,4,5,8,9,12,13

       Setting cpus_in_rad to 2 on this system would result in the following
       resource affinity domain configuration:

        RAD[0] - cpus 0, 1 
        RAD[2] - cpus 4, 5 
        RAD[4] - cpus 8, 9 
        RAD[6] - cpus 12, 13 

       Setting cpus_in_rad to 4 on this system would result in the following
       resource affinity domain configuration:

        RAD[0] - cpus 0, 1 (2 and 3 are missing)
        RAD[1] - cpus 4, 5 (6 and 7 are missing)
        RAD[2] - cpus 8, 9 (10 and 11 are missing)
        RAD[3] - cpus 12, 13 

Interaction of cpus_in_rad and the rad_gh_regions tunables:

    When cpus_in_rad is increased, the number or RADs configured decreases. 
    If the system is configured with settings for rad_gh_regions, those
    settings must also be changed.

    Consider a system configured with cpus 0,1,4,5,8,9,12,13 and rad_gh_regions 


    configured to allocate 4 Gigabytes of granularity hint memory. With the 
    default setting of cpus_in_rad (zero) or cpus_in_rad set to 1, 
    rad_gh_regions would have the following settings:

        rad_gh_regions[0] = 512 
        rad_gh_regions[1] = 512 
        rad_gh_regions[4] = 512 
        rad_gh_regions[5] = 512 
        rad_gh_regions[8] = 512 
        rad_gh_regions[9] = 512 
        rad_gh_regions[12] = 512 
        rad_gh_regions[13] = 512 

    If the system is configured to place 2 cpus in a rad (cpu_in_rad=2), 
    the rad_gh_regions settings would need to be changed to the following:

        rad_gh_regions[0] = 1024 
        rad_gh_regions[2] = 1024 
        rad_gh_regions[4] = 1024 
        rad_gh_regions[6] = 1024 

    Because of how missing cpus are handled, if cpus_in_rad is set to 4, the
    RADs would still contain only 2 cpus (2 existing, 2 missing) but the
    rad numbers change, so rad_gh_regions would have the following settings:

        rad_gh_regions[0] = 1024 
        rad_gh_regions[1] = 1024 
        rad_gh_regions[2] = 1024 
        rad_gh_regions[3] = 1024 

vm: vm_overflow

    When memory resources are depleted on a RAD in a NUMA system, the vm
    subsystem will automatically overflow to another RAD to fulfill the 
    memory allocation request. The default overflow behavior is to:

        attempt an allocation from the "local" RAD
        if that fails, page out a page of memory and "steal" it
        if that fails, attempt an allocation from the "next" RAD
        if that fails, page out a page on that RAD and "steal" it.
        This continues until allocation/stealing has been attempted on all
        RADs.

    Setting the vm_overflow tunable to 1 changes the order of page allocations
    and page stealing:

        attempt an allocation from the "local" RAD
        if that fails, attempt an allocation from the "next" RAD
        This continues until allocation has been attempted on all RADs.
        If the memory allocation is still not successful revert back to
        the original behavior stated above.

    Using a setting of 1 may result in less paging activity for some
    applications and improve performance.



3 Summary of CSPatches contained in this kit


Tru64 UNIX V5.1B

PatchId			Summary Of Fix
----------------------------------------
C1884.00			Fixes to cpu_in_rad, gh_chunks and  UBC


4 Additional information from Engineering


None


5 Affected system files
This patch delivers the following files:

Tru64 UNIX V5.1B
	Patch C1884.00
		./sys/BINARY/arch_alphapmap.mod
			CHECKSUM:	52033 351
			SUBSET:	OSFHWBIN540
		./sys/BINARY/generic.mod
			CHECKSUM:	50039 12
			SUBSET:	OSFBIN540
		./sys/BINARY/marvel_cpu.mod
			CHECKSUM:	28870 147
			SUBSET:	OSFHWBIN540
		./sys/BINARY/marvel_soc.mod
			CHECKSUM:	10168 237
			SUBSET:	OSFHWBIN540
		./sys/BINARY/vfs.mod
			CHECKSUM:	51074 656
			SUBSET:	OSFBIN540
		./sys/BINARY/vm.mod
			CHECKSUM:	32272 674
			SUBSET:	OSFBIN540
		./usr/sys/BINARY/alpha_init.o
			CHECKSUM:	47020 142
			SUBSET:	OSFHWBIN540
		./usr/sys/BINARY/pmap_init.o
			CHECKSUM:	63788 145
			SUBSET:	OSFBIN540
