Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Installing /RESIDENT - demand on GH region?

 
John McL
Trusted Contributor

Installing /RESIDENT - demand on GH region?

I've tried several times to install an executable image with /RESIDENT.  I've linked it according to the documentation so that should be okay.  Each time I try to install I get the error message(s)

 

%INSTALL-I-NONRES, image installed ignoring '/RESIDENT' DISK_1:<directory><image_name>
-INSTALL-E-NOGHREG, insufficient memory in the code or data granularity hint region

 

The system has 2Gb of memory of which about 90% is curently free.  SHOW MEMORY/GH gives ...

 

Granularity Hint Regions (pages):   Total        Free      In Use    Released
  Execlet code region                2560           0        1494        1066
  Execlet data region                 512           0         488          24
  S0S1 Executive data region         3868           0        3868           0
  S0S1 Resident image code region    1024           0         675         349

 

Well, the "Free" is 0 but "released" looks as if it should be adequate seeing how I'm installing /RESIDENT=CODE

 

The image is quite small.  The ISD's total 23280 bytes, or when each ISD is rounded to Alpha pages (of 8K each) the total is 144 pagelets or 9 Alpha pages.  (It doesn't mean a lot, but the .EXE is just 82 pages - presumably pagelets - and it doesn't contain huge arrays)

 

We've tried twice to increase the GH region but because we rebooted after each attempt I'd rather not keep trying without having at least reasonable confidence that the next reboot should be the last.

 

Two questions -

1 - How can I determine how many pages in the GH region are needed to install an image /RESIDENT 

2 - Is something wrong with my thinking above (e.g. does space need to be availavle in S0S1 data region even though I'm only installing /RESIDENt=CODE)

 

And I suppose I should ask whether the error message is accurate or a generic message for several situations, even HELP/MESSAGE doesn't help a lot.

 

 

5 REPLIES 5
x2084
Trusted Contributor

Re: Installing /RESIDENT - demand on GH region?

You didn't say so, but it seems to be Alpha: there is no need to do a special link on I64. By default, at the end of the system startup unused pages of the resident image GH region are released to the free list. There are two sysgen parameters to control that. LOAD_SYS_IMAGES to keep all unused pages in the GH regions. GH_RSRVPGCNT to keep a specified amount of pages in the resident image code GH region. The amount of pages you need to reserve is the number of pages of all ISDs flagged as EXE. Analyze/image should help to determine that number. A practical approach is to change LOAD_SYS_IMAGES so that the pages aren't released. Then reboot. Now you can see what installing /RESIDENT really uses. Then you can set GH_RSRVPGCNT accordingly. Then you have to reset LOAD_SYS_IMAGES and reboot, again. I think, this is all documented somewhere in the System Management manuals.
John Gillings
Honored Contributor

Re: Installing /RESIDENT - demand on GH region?

John,

 

   The way this stuff works is at boot time you allocate some huge pages for the GH region and populate them with INSTALL/RESIDENT. Near the end of the boot sequence, any "leftover" GH pages are "released". That means they still map to the unused end of the GH region, but they're given back to the free list for general use. Once released, they're no longer available as GH pages.  This is done because the pages are so big, and the space would be otherwise wasted.

 

  So, one way to fix this would be to make sure your images are installed during the startup, before the excess is released. Another is to use GH_RSRVPGCNT to keep up to that many pages free in the GH region. Working out how much space your image will use can be done from a MAP file, or by experiment.

 

  For a stable image, you don't need to reserve anything, just install it at boot time. For one you're working on, I'd recommend reserving at least 3x the space required, to give you enough headroom to /REPLACE the image, even if another process has it open, and allow for some fragmentation (especially true if you're juggling developement of several images)

A crucible of informative mistakes
John McL
Trusted Contributor

Re: Installing /RESIDENT - demand on GH region?

Thanks John G, done that, with GH_RSRVPGCNT set to 30, rebooted, and INSTALL/RESIDENT reports no errors.

 

I'm a bit puzzled though. On a test of 10,000 execution cycles the image, which uses shareable DECC$SHR, LIBRTL, LIBOTS and SYS$PUBLIC_VECTORS runs no faster when it's installed /RESIDENT than when it's installed /OPEN/HEADER/SHARED.

 

I expected a performance improvement because my understanding is that /RESIDENT will do all the "fixups" when the image is installed, the shareables (inc. SYS$PUBLIC_VECTORS ?) are all installed /RESIDENT and indeed a LIST/FULL shows the image to be installed resident.

 

What am I missing here?

John Gillings
Honored Contributor

Re: Installing /RESIDENT - demand on GH region?

John,

 

   Just installing an image resident will save you reading the image from disk, but you will still (soft) fault the pages into your working set. Since the pages are "huge", you get less faults overall. Yes, outbound fixups are done, but unless you have LOTS of them, I'd be surprised if you could measure any difference in activation time. As you said, your image is fairly small. Even if all those 82 pagelets were fixups, how long would they take to process, relative to (say) the disk I/O required to read the image?

 

  Remember /SHARE and /RESIDENT are most beneficial when you have many processes executing the same code. The real savings are system wide, rather than per process.

 

On the other hand, maybe experiment by defining logical names for ALL the images in the dependence tree with version numbers (to bypass known image activation). Compare activating all resident with all private:

 

$ DEFINE yourimage   dev:[dir]yourimage.EXE;
$ DEFINE DECC$SHR    SYS$SHARE:DECC$SHR.EXE;
$ DEFINE LIBRTL      SYS$SHARE:LIBRTL.EXE;
$ DEFINE CMA$TIS_SHR SYS$SHARE:CMA$TIS_SHR.EXE;
$ DEFINE LIBOTS      SYS$SHARE:LIBOTS.EXE;
$ DEFINE DPML$SHR    SYS$SHARE:DPML$SHR.EXE;
$ RUN yourimage

 

 

A crucible of informative mistakes
x2084
Trusted Contributor

Re: Installing /RESIDENT - demand on GH region?

>>>I expected a performance improvement because my understanding is that /RESIDENT will do all the "fixups" when the image is installed ...

Yes, outbound fixups are done, but unless you have LOTS of them, ...

<<<

 

No. /RESIDENT does not cause INSTALL to do any fixup. You need /SHARE=ADDRESS to let INSTALL apply the fixups. As you said, you wanted to move code into resident memory. Fixups are not applied to code ISDs. They are applied to address data, which is not executable. Without /SHARE=ADDRESS this address data is mapped to P0 at activation time and fixups are done at activation time. With /SHARE=ADDRESS this address data is mapped at a system wide fixed P1 address. That enables INSTALL to apply fixups, no matter where the code is mapped.