- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Installing /RESIDENT - demand on GH region?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2011 06:03 PM
07-24-2011 06:03 PM
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.
- Tags:
- resident
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2011 02:43 AM
07-25-2011 02:43 AM
Re: Installing /RESIDENT - demand on GH region?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2011 02:30 PM
07-25-2011 02:30 PM
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2011 05:54 PM
07-26-2011 05:54 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2011 06:49 PM
07-26-2011 06:49 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2011 12:53 AM
07-27-2011 12:53 AM
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.