Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

It's not a huge performance issue but it should definitely be cleaned up.  I'll 
submit an RFE and Share requirement.  We'll see who wants to jump on the 
bandwagon.

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, June 3, 2021 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

IBM takes formal customer requests into account. If you need it, then it is in 
your best interest to submit a formal requirements and to ask others to endorse 
it, whether that be a direct RFE or a SHARE requirement. It's really a win-win 
proposition; it helps you and it helps IBM.


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!QMUuiuZCVrO-GbcjmeQ6mA3kR9wvJYFrD1ahHbKd0G6UpmX7n61Ed8oSwKxLkEsS8xY$
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Crawford, Robert C. [01feadb2c2d2-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 3, 2021 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Jim,

Thank you for the explanation.  It is WAD (working as designed).

Do I need to submit a formal requirement or is being on the list sufficient?

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire 
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Here's what happened:

Apar: OA41307
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES Closed Date: 13/02/23 
RSM support for FORK copies high virtual memory objects from the parent address 
space to the child as part of duplicating the parent process' address space. 
However, the request currently fails if the parent process owns high virtual 
that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will be demoted to 4k pages 
and copied into the child address space.


  The easiest and safest solution for the APAR was to simply demote the source 
1MB pages so the the existing code could then handle them.  Over the years, RSM 
has changed other functions to reduce the number of cases where demotion is 
done. For example, z/OS 2.2 avoids demotion when possible for PGSER FIX. and 
z/OS 2.3 tries to avoid demotion when
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, ForkCopy slipped 
through the cracks.  As a result of your question, it is being added to the 
list of things to look at for a future release.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C."
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion 
> [Internal] Sent by: "IBM Mainframe Discussion List"
> 
>
> Here is the full trace.  I'll gladly accept any help in interpreting.
>
> Sorry about the bad formatting.
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU.
> 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET
> 0800 ADASID.. 0215 XMASID.. 022D CMASID.. 
> STASID.. 
>  KEY. 0036 ADDR 035E1008 ALET 
>  70207520 C710
>  KEY. 009A ADDR 035E22B0 ALET 
>  035E22F8      0100
>       
>   
>  
>  KEY. 009B ADDR 035E22F8 ALET 
>  0001 0103 7FF74D38 04134B00 003B E5398D00 
>    0050 1A00  
>   
>  
>
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822




-

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Seymour J Metz]

IBM takes formal customer requests into account. If you need it, then it is in 
your best interest to submit a formal requirements and to ask others to endorse 
it, whether that be a direct RFE or a SHARE requirement. It's really a win-win 
proposition; it helps you and it helps IBM.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Crawford, Robert C. [01feadb2c2d2-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 3, 2021 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Jim,

Thank you for the explanation.  It is WAD (working as designed).

Do I need to submit a formal requirement or is being on the list sufficient?

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Here's what happened:

Apar: OA41307
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES Closed Date: 13/02/23 
RSM support for FORK copies high virtual memory objects from the parent address 
space to the child as part of duplicating the parent process' address space. 
However, the request currently fails if the parent process owns high virtual 
that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will be demoted to 4k pages 
and copied into the child address space.


  The easiest and safest solution for the APAR was to simply demote the source 
1MB pages so the the existing code could then handle them.  Over the years, RSM 
has changed other functions to reduce the number of cases where demotion is 
done. For example, z/OS 2.2 avoids demotion when possible for PGSER FIX. and 
z/OS 2.3 tries to avoid demotion when
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, ForkCopy slipped 
through the cracks.  As a result of your question, it is being added to the 
list of things to look at for a future release.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C."
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion
> [Internal] Sent by: "IBM Mainframe Discussion List"
> 
>
> Here is the full trace.  I'll gladly accept any help in interpreting.
>
> Sorry about the bad formatting.
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU.
> 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET
> 0800 ADASID.. 0215 XMASID.. 022D CMASID.. 
> STASID.. 
>  KEY. 0036 ADDR 035E1008 ALET 
>  70207520 C710
>  KEY. 009A ADDR 035E22B0 ALET 
>  035E22F8      0100
>       
>   
>  
>  KEY. 009B ADDR 035E22F8 ALET 
>  0001 0103 7FF74D38 04134B00 003B E5398D00 
>    0050 1A00  
>   
>  
>
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

Jim,

Thank you for the explanation.  It is WAD (working as designed).

Do I need to submit a formal requirement or is being on the list sufficient?

Thanks again.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

Here's what happened:

Apar: OA41307
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES Closed Date: 13/02/23 
RSM support for FORK copies high virtual memory objects from the parent address 
space to the child as part of duplicating the parent process' address space. 
However, the request currently fails if the parent process owns high virtual 
that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will be demoted to 4k pages 
and copied into the child address space.


  The easiest and safest solution for the APAR was to simply demote the source 
1MB pages so the the existing code could then handle them.  Over the years, RSM 
has changed other functions to reduce the number of cases where demotion is 
done. For example, z/OS 2.2 avoids demotion when possible for PGSER FIX. and 
z/OS 2.3 tries to avoid demotion when
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, ForkCopy slipped 
through the cracks.  As a result of your question, it is being added to the 
list of things to look at for a future release. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion 
> [Internal] Sent by: "IBM Mainframe Discussion List" 
> 
> 
> Here is the full trace.  I'll gladly accept any help in interpreting.
> 
> Sorry about the bad formatting.
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page  
>  FUNC1... COPYSRVH  High Virtual Copy Service  
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 
> 0006  
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 
> 0800 ADASID.. 0215 XMASID.. 022D CMASID..  
> STASID..  
>  KEY. 0036 ADDR 035E1008 ALET   
>  70207520 C710  
>  KEY. 009A ADDR 035E22B0 ALET   
>  035E22F8      0100
>       
>   
>    
>  KEY. 009B ADDR 035E22F8 ALET   
>  0001 0103 7FF74D38 04134B00 003B E5398D00 
>    0050 1A00  
>   
>  
> 
> 
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Jim Mulder]

Here's what happened:

Apar: OA41307 
Abstract: FORK FAILURE WHEN ADDRESS SPACE OWNS 1MEG PAGES
Closed Date: 13/02/23
RSM support for FORK copies high virtual memory objects
from the parent address space to the child as part of
duplicating the parent process' address space. However,
the request currently fails if the parent process owns
high virtual that consists of one megabyte pages.

PROBLEM CONCLUSION:

TEMPORARY FIX:
*
* HIPER *
*

COMMENTS:
All pageable 1M pages in the parent address space will
be demoted to 4k pages and copied into the child address
space.


  The easiest and safest solution for the APAR was to simply 
demote the source 1MB pages so the the existing code 
could then handle them.  Over the years, RSM has changed
other functions to reduce the number of cases where demotion
is done. For example, z/OS 2.2 avoids demotion when possible for 
PGSER FIX. and z/OS 2.3 tries to avoid demotion when 
IARV64 PAGEFIX  fixes a portion of a 1MB page.  Unfortunately, 
ForkCopy slipped through the cracks.  As a result
of your question, it is being added to the list of things to look 
at for a future release. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
06/02/2021 04:49:14 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 10:35 PM
> Subject: Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page 
> Demtion [Internal]
> Sent by: "IBM Mainframe Discussion List" 
> 
> Here is the full trace.  I'll gladly accept any help in interpreting.
> 
> Sorry about the bad formatting.
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page  
>  FUNC1... COPYSRVH  High Virtual Copy Service  
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 
> 0006  
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 
> 0800 ADASID.. 0215 XMASID.. 022D CMASID..  
> STASID..  
>  KEY. 0036 ADDR 035E1008 ALET   
>  70207520 C710  
>  KEY. 009A ADDR 035E22B0 ALET   
>  035E22F8      0100 
>        
>   
>    
>  KEY. 009B ADDR 035E22F8 ALET   
>  0001 0103 7FF74D38 04134B00 003B E5398D00  
>    0050 1A00   
>   
>    
> 
> 
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

Here is the full trace.  I'll gladly accept any help in interpreting.

Sorry about the bad formatting.

SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
 
 FUNC1... COPYSRVH  High Virtual Copy Service   
 
 JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
 
 JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800 
ADASID.. 0215 XMASID.. 022D CMASID..  STASID..  
 KEY. 0036 ADDR 035E1008 ALET   
 
 70207520 C710  
 
 KEY. 009A ADDR 035E22B0 ALET   
 
 035E22F8      0100  
        
    
 
 KEY. 009B ADDR 035E22F8 ALET   
 
 0001 0103 7FF74D38 04134B00 003B E5398D00   
  0050 1A00     
    
 


Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Wednesday, June 2, 2021 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

  Please show the entire trace entry.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on
06/01/2021 04:12:18 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 12:06 PM
> Subject: Why Would COPYSRVH Cause a 1M Page Demtion [Internal] Sent 
> by: "IBM Mainframe Discussion List" 
> 
> I've been trying to track down what's causing system 1M page demotions 
> on our test system.  The component trace IBM gave me shows, in
part:
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
> 
> The COPYSRVH function isn't well documented but, from I see, UNIX fork 
> processing invokes it to copy memory to the new process.  This makes 
> sense in that JOBN1 and JOBN3 are both USS processes.
> 
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/ 
> OS demoting pages?



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Jim Mulder]

  Please show the entire trace entry.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
06/01/2021 04:12:18 PM:

> From: "Crawford, Robert C." 
<01feadb2c2d2-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2021 12:06 PM
> Subject: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]
> Sent by: "IBM Mainframe Discussion List" 
> 
> I've been trying to track down what's causing system 1M page 
> demotions on our test system.  The component trace IBM gave me shows, in 
part:
> 
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
> 
> The COPYSRVH function isn't well documented but, from I see, UNIX 
> fork processing invokes it to copy memory to the new process.  This 
> makes sense in that JOBN1 and JOBN3 are both USS processes.
> 
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/
> OS demoting pages?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

It wasn't a page fix request in this instance unless RSM wants to fix pages 
while it does a massive copy of memory from one process to another.

This is a 2.3 system.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » – Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

Classification: Internal



Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Tuesday, June 1, 2021 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

IARV64 pagefix will cause demotion if the area is not 1MB on a 1MB boundary.  
This was fixed in z/os 2.3 ... what release/ptf level are you running?

On Wed, Jun 2, 2021 at 6:12 AM Crawford, Robert C. < 
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> I've been trying to track down what's causing system 1M page demotions 
> on our test system.  The component trace IBM gave me shows, in part:
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
>
> The COPYSRVH function isn't well documented but, from I see, UNIX fork 
> processing invokes it to copy memory to the new process.  This makes 
> sense in that JOBN1 and JOBN3 are both USS processes.
>
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/OS 
> demoting pages?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> « Des clochards comme nous, bébé nous sommes nés pour courir » - 
> Voltaire Please send requests to mainframe management through our 
> front door at go/mfmfrontdoor< 
> https://urldefense.com/v3/__https://onc.jira.usaacloud.com/secure/Dash
> board.jspa?selectPageId=15466__;!!GryZGb6B1VCs0SfC!XavpJVotC1FDzbPYC6D
> UPI2ZAGWiVF08MgtKLVmLjoEb0U3yAV8t9Ev7UE96IhgV-cw$ >
>
> Classification: Internal
>
> Disclaimer: This email and any attachments are the property of USAA 
> and may contain confidential and/or privileged material. If you are 
> not the intended recipient, any use, disclosure or copying of this 
> email or any attachments is unauthorized. If you received this email 
> in error, please immediately notify the sender and delete the email 
> and any attachments from your computer.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Attila Fogarasi]

IARV64 pagefix will cause demotion if the area is not 1MB on a 1MB
boundary.  This was fixed in z/os 2.3 ... what release/ptf level are you
running?

On Wed, Jun 2, 2021 at 6:12 AM Crawford, Robert C. <
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> I've been trying to track down what's causing system 1M page demotions on
> our test system.  The component trace IBM gave me shows, in part:
>
> SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
>  FUNC1... COPYSRVH  High Virtual Copy Service
>  JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
>  JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
>  KEY. 0036 ADDR 035E1008 ALET 
>
> The COPYSRVH function isn't well documented but, from I see, UNIX fork
> processing invokes it to copy memory to the new process.  This makes sense
> in that JOBN1 and JOBN3 are both USS processes.
>
> Both LFAREA and SCM on this system are less than 1% used.  Why is z/OS
> demoting pages?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> « Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
> Please send requests to mainframe management through our front door at
> go/mfmfrontdoor<
> https://onc.jira.usaacloud.com/secure/Dashboard.jspa?selectPageId=15466>
>
> Classification: Internal
>
> Disclaimer: This email and any attachments are the property of USAA and
> may contain confidential and/or privileged material. If you are not the
> intended recipient, any use, disclosure or copying of this email or any
> attachments is unauthorized. If you received this email in error, please
> immediately notify the sender and delete the email and any attachments from
> your computer.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Why Would COPYSRVH Cause a 1M Page Demtion [Internal]

[Crawford, Robert C.]

I've been trying to track down what's causing system 1M page demotions on our 
test system.  The component trace IBM gave me shows, in part:

SYS5  SGTDEM64  0063  12:44:53.270019  Demote 1M 64 bit page
 FUNC1... COPYSRVH  High Virtual Copy Service
 JOBN1... ZUMCCMG1 ASID1... 0215 PLOCKS.. 8800C001 CPU. 0006
 JOBN2... ZUMCCMG3 ASID2... 022D RLOCKS.. 8800C001 RLOCKDET 0800
 KEY. 0036 ADDR 035E1008 ALET 

The COPYSRVH function isn't well documented but, from I see, UNIX fork 
processing invokes it to copy memory to the new process.  This makes sense in 
that JOBN1 and JOBN3 are both USS processes.

Both LFAREA and SCM on this system are less than 1% used.  Why is z/OS demoting 
pages?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

« Des clochards comme nous, bébé nous sommes nés pour courir » - Voltaire
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

Classification: Internal

Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN