Re: CSA page tables
Thanks, Jim. That answers my question rather completely. [:)] Dave (I know what I need to do to fix this. I'm just curious about what good reason IBM might or might not have for doing this.) (1) Pageable common storage (pageable CSA and DREF SQA) can exist in the same segment as fixed common storage (fixed CSA and non-DREF SQA). Pageable common storage processing in RSM is serialized by the Common RSMAD lock. Fixed common storage processing in RSM is serialized by the RSMGL lock. If these two types of processing could allocate and deallocate page tables, they would be doing so unserialized against each other. (2) It has certainly been this way at least since the beginning of MVS/XA. I didn't work on RSM much back in MVS/370, so I would hesitate to speculate on how it worked. However, the locking was simpler in MVS/370 - all of common storage processing in both VSM and RSM was serialized by the SALLOC lock. The The VSMPAG, VSMFIX, RSMAD, RSM, and RSMGL locks were introduced in MVS/XA (and the SALLOC lock became unused) in order to reduce SALLOC lock contention. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CSA page tables
Hi All, I have just discovered that for extended CSA, page tables exist for all storage within the CSA, even for whole segments (mega-byte chunks) that are in unallocated storage. In other words, for CSA storage, even when every page within a segment's page table is flagged as being invalid (x'0400'), (a) the page table continues to exist, and (b) the segment table entry pointing to that page table is *NOT* flagged as being invalid! I have two questions: (1) Why does IBM do this? (2) Has it always been this way? (I think not, but I'm not sure.) Why do I care? Well, I have a storage search routine that traps the program checks that occur when unallocated storage is reached, and examines the PIC codes to figure out how far ahead to jump to step over the hole. This logic works great for private storage, but for CSA, I wind up getting 71-THOUSAND page faults instead of only a few hundred segment faults. Consequently, a scan that should take only a few seconds winds up taking between a quarter and a half hour. (I know what I need to do to fix this. I'm just curious about what good reason IBM might or might not have for doing this.) Thanks, Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA page tables
On Mon, 2 Jan 2006 15:37:09 -0500, David Cole [EMAIL PROTECTED] wrote: (I know what I need to do to fix this. I'm just curious about what good reason IBM might or might not have for doing this.) RSU ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA page tables
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/02/2006 03:37:09 PM: I have just discovered that for extended CSA, page tables exist for all storage within the CSA, even for whole segments (mega-byte chunks) that are in unallocated storage. In other words, for CSA storage, even when every page within a segment's page table is flagged as being invalid (x'0400'), (a) the page table continues to exist, and (b) the segment table entry pointing to that page table is *NOT* flagged as being invalid! I have two questions: (1) Why does IBM do this? (2) Has it always been this way? (I think not, but I'm not sure.) Why do I care? Well, I have a storage search routine that traps the program checks that occur when unallocated storage is reached, and examines the PIC codes to figure out how far ahead to jump to step over the hole. This logic works great for private storage, but for CSA, I wind up getting 71-THOUSAND page faults instead of only a few hundred segment faults. Consequently, a scan that should take only a few seconds winds up taking between a quarter and a half hour. (I know what I need to do to fix this. I'm just curious about what good reason IBM might or might not have for doing this.) (1) Pageable common storage (pageable CSA and DREF SQA) can exist in the same segment as fixed common storage (fixed CSA and non-DREF SQA). Pageable common storage processing in RSM is serialized by the Common RSMAD lock. Fixed common storage processing in RSM is serialized by the RSMGL lock. If these two types of processing could allocate and deallocate page tables, they would be doing so unserialized against each other. (2) It has certainly been this way at least since the beginning of MVS/XA. I didn't work on RSM much back in MVS/370, so I would hesitate to speculate on how it worked. However, the locking was simpler in MVS/370 - all of common storage processing in both VSM and RSM was serialized by the SALLOC lock. The The VSMPAG, VSMFIX, RSMAD, RSM, and RSMGL locks were introduced in MVS/XA (and the SALLOC lock became unused) in order to reduce SALLOC lock contention. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
