Patch Name: PHKL_7244 Patch Description: s700 10.10 Fix in smmap for file systems that don't do ACLs Creation Date: 96/04/10 Post Date: 96/04/12 Repost: 96/12/19 The Symptoms specify "MP T500", however any multiprocessor running database applications can suffer this problem. The documentation has been modified accordingly. Hardware Platforms - OS Releases: s700: 10.10 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_7244: OTHER Performance problems caused by excessive protection id faults Path Name: /hp-ux_patches/s700/10.X/PHKL_7244 Symptoms: PHKL_7244: Multi-processor systems running 10.01 or 10.10 with Informix database exhibits poor performance and high levels of protection id traps after reboot. Problem exhibits itself after stopping/restarting application until system rebooted. /usr was a JFS VxFS file system. Defect Description: PHKL_7244: We only allow a public mapping if we are mapping shared (and thus read-only for now) and if the file's modes meet our tests (no ACL, and mode at least r-xr-xr-x). In one case, /usr (where the shared libraries reside) on their system turns out to be a JFS file system. JFS does not know about ACL and does not manipulate the va_acl bit in 'struct vattr', when VOP_GETATTR() is called. HFS on the other hand will set va_acl to 1 if that file has ACL and 0, if not. Since, smmap() does not initialize the structure (on the stack) and calls VOP_GETATTR() and then looks at the va_acl bit, it can either be a 1 or a 0, randomly. It is not correct for VM subsystem to assume all file systems support ACL and will correct set/reset the bit in the vattr structure as there could be third party file system (eg: JFS) that do not support it. When the libc.1 is first mmapp'ed, the smmap() code finds that va_acl is set (wrongly), it decides not to do public mapping (the region does not get the RHDL_MMAP_PUBLIC set) and so the protection id is set to the second quadrant space id of that process, instead of the public protection id of 0 Since, the informix (oninit) processes have a lot of shared memory segments, each of which has an unique protection id, and constantly accesses the shared memory region and execute library code, the protection id (pid3 & pid4) is getting thrashed in the pid registers. The instruction protection fault code is getting thrashed in the pid registers. The instruction protection fault code (IMEM_PROT) does not make use of the cache (kept per processor) and always uses the trap (long) path to update the protection registers. Hence, you see about 30-40% of the time in trap code. The following fix will ensure that the shared library text segments always get the public protection id. This will cut down the number of protection faults seen in informix. SR: 4701319335 Patch Files: /usr/conf/lib/libhp-ux.a(vm_mmap.o) what(1) Output: /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 96/04/10 14:30:56 $ $Revision : 1.13.89.18 $ PATCH_10.10 (PHKL_7244) cksum(1) Output: 507374109 19944 /usr/conf/lib/libhp-ux.a(vm_mmap.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: None Equivalent Patches: PHKL_7242: s700: 10.01 PHKL_7243: s800: 10.01 PHKL_7245: s800: 10.10 Patch Package Size: 70 Kbytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHKL_7244 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_7244.depot 5b. For a homogeneous NFS Diskless cluster run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This will invoke swcluster in the interactive mode and force all clients to be shut down. WARNING: All cluster clients must be shut down prior to the patch installation. Installing the patch while the clients are booted is unsupported and can lead to serious problems. The swcluster command will invoke an swinstall session in which you must specify: alternate root path - default is /export/shared_root/OS_700 source depot path - /tmp/PHKL_7244.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFS Diskless cluster: - run swinstall on the server as in step 5a to install the patch on the cluster server. - run swcluster on the server as in step 5b to install the patch on the cluster clients. The cluster clients must be shut down as described in step 5b. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_7244. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. Warning: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_7244.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_7244.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None