README VERSION : 1.1 README CREATION DATE : 2012-09-26 PATCH ID : 5.1.113.000 PATCH NAME : VRTSglm 5.1SP1RP3 BASE PACKAGE NAME : VRTSglm BASE PACKAGE VERSION : 5.1.0.0 SUPERSEDED PATCHES : 5.1.112.100 REQUIRED PATCHES : 5.1.100.000 INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : aix53,aix61,aix71 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : OTHER PATCH CRITICALITY : OPTIONAL HAS KERNEL COMPONENT : NO ID : NONE REBOOT REQUIRED : NO PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to the Release Notes for Install instructions. PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to the Release Notes for Uninstall Instructions. SPECIAL INSTRUCTIONS: ---------------------- NONE KNOWN ISSUES : FIXED INCIDENTS: PATCH ID:5.1.113.000 Repackage 5.1SP1RP2P1 as 5.1SP1RP3. Patch Id::5.1.112.100 This glm patch contain internal fix. Patch Id::5.1.112.0 * Incident no::2406572 Tracking ID ::2146573 Symptom::Customer reported this as performance issue. The application was running slower when this problem happens. The SAR utility on HP-UX was showing some processes in PRI state. Description::(1) Complexity: This is an extremely complex performance concern in an environment where different applications are in great competition for the same system-wide resources. (2) Performance overheads: Competition for system resources is expected. However intense competition can create large overheads due to increased repetitive initialization. We approached this issue in multiple ways. Provided customer some tuning and application changes. Resolution::No product bug was identified from Symantec side. However a GLM patch was provided to customer which does two things. 1. Different names given to different GLM spin locks. So that we can identify various locks from spin watcher output. 2. We take avoiding a spinlock which keeps accounting if how many times allocation did in GLM. Removing this lock will not cause any regression. Also, we have not said that it will solve this performance problem. * Incident no::2412137 Tracking ID ::2346730 Symptom::On the AIX platform a method of identifying the pinned memory in use by VxFS and GLM is required. Description::The VxFS inode cache, buffer cache and Directory Name lookup Cache (DNLC) are the main consumers of pinned memory by VxFS. We require counters detailing the total pinned memory in use by VxFS and total in use by GLM, plus a break down of the pinned memory in-use for these three VxFS caches Resolution::New vxfsstat counters have been added to track the VxFS pinned memory usage, the VxFS counters can be displayed using the 'vxfsstat -m' option. A new option to glmstat has been added to display the current pinned memory inuse by GLM. This new option is 'glmstat -p'. * Incident no::2554253 Tracking ID ::2230240 Symptom::HP 5.1 SP1 GLMQA test hit an assert "Unaligned reference fault in kernel" in internal testing. Description::We are trying to access gm_range members from msg directly, which are not 64-bit aligned. Resolution::Fixing the unaligned access fault by using bcopy and then accessing the struct members. Incidents from old Patches: --------------------------- NONE