gh_exec_data system parameter

[Stephen Daddona]

Do any of you folks know what the VMS system parameter GH_EXEC_DATA does? All I can find about it is the short description in the System Manager's manual.


Thanks in advance!

[Ian McKerracher_1]

Hello Craig,

I have never been involved with granularity hint regions before but I can give you another description of the SYSGEN parameter GH_EXEC_DATA. It is the size of the executive image data huge page. As a matter of interest, GH_EXEC_CODE is the size of the executive image code huge page.

According to my infrequently used copy of OpenVMS Alpha Internals - "During system initialisation, OpenVMS creates one or more granularity hint regions for several specific uses. The term 'huge page' refers to the granularity hint region or regions associated with each of these particular uses. A huge page consists of more than one granularity hint region if it requires more physical pages than can be mapped by one TB entry."

If you require any further assistance I am sure our learned colleagues will be more than happy to help when they log in tomorrow.

Regards,

Ian

[Stephen Daddona]

So it sounds like it's a parameter that VMS uses for it's own self and I shouldn't worry about it when Autogen wants to decrease it.

[John Gillings]

Craig,

"Granularity Hint Regions" are a neat way of speeding up virtual address translations. "Huge pages" are large chunks of virtually and physically contiguous pages allocated at boot time, so that they can all be addressed through a single page table entry. This skips an entire level of virtual address translation.

This can only be done at boot time, before memory has had a chance to be fragmented. There are some SYSGEN parameters to control how much memory is allocated for system use (GH_EXEC_CODE and GH_EXEC_DATA), and user (GH_RES_CODE, GH_RES_DATA and GH_RERVPGCNT).

You're unlikely to ever need to mess with the GH_EXEC* parameters, but if you want to install your own /RESIDENT images, you may need to adjust the GH_RES* parameters to allocate sufficient space.

See SHOW MEMORY "Granularity Hint Regions" to see how it's configured on your system.

[Ian McKerracher_1]

Hello Craig,

I believe that granularity hint regions (GHRs) are not subject to paging. Is it possible that something has changed on your system recently and Autogen is not prepared to allocate so much memory to GHRs next time you boot your system?


Regards,

Ian

[Stephen Daddona]

This is a recently purchased used system (ES40) and we just got it moved over as our production system two weeks ago. I had run Autogen with "savparams genparams feedback" and noticed that autogen wants to reduce gh_exec_data from 512 to 448. SHOW MEM shows this:
Granularity Hint Regions (pages): Total Free In Use Released
Execlet code region 1024 112 762 150
Execlet data region 512 131 273 108

The main reason that I asked the original question was that our Fall semester starts Aug 29 and we always get a BIG jump in usage the first two days with students adding and dropping classes. So I wanted to know if I should be concerned about VMS reducing that value.

[John Gillings · Accepted solution]

Craig,

>So I wanted to know if I should be
>concerned about VMS reducing that value.

Not at all. Each "huge page" is 512 pagelets of virtually and physically contiguous memory. Obviously it's unlikely that the stuff OpenVMS copies into the region will fit exactly, so once everything is done, OpenVMS releases any left over pages to the free list.

So, those physical pages will still be mapped to the Granularity Hint Region, but they're also available to be mapped to other virtual addresses by other processes.

It's "safe" to do this because the GHR is exec access only, and we can trust the exec code to not overstep their memory boundaries.

AUTOGEN will reduce GH_EXEC_DATA if it sees unused pages in the GHR. The important thing to remember is that all this happens at boot time. Once the system is running, there are no changes to the GH_EXEC* regions, regardless of workload. Indeed, freeing up these pages is GOOD for you since it makes a few more pages of memory available to help handle the increased load.

On the other hand, the GH_RES* regions can be subject to changes over time (for example, if you want to install and uninstall /RESIDENT images), so those paramters can be used to "protect" apparently unused pages at the end of those GHRs to prevent them from being freed for other purposes.

[Stephen Daddona]

Thanks, both Ian and John. You learn something new every day!