Getting the most out of FREPTECNT

[Travis Craig]

I am trying to monitor how much virtual address space one of my processes is using (a 32-bit process on an Alpha, with OpenVMS V7.3-1 or 7.3-2). I have QUOTA.COM and several derivatives of it with which I can monitor page file quota, how much page file quota is left, working set usage, etc. I don't want to know about only page file use and I don't care at all about physical memory (working set). I want to know how much virtual address space the process is using. Page file doesn't do it for me because my processes have most of their address space mapped to global sections. It looked like JPI$_APTCNT would tell me what I want, but it doesn't seem to return much of anything besides zero. My second choice is JPI$_FREPTECNT, but it tells me how many page table entries I have left, a number which is just shy of 15 billion pagelets throughout the entire range of memory usage by my process, from startup until it runs out of P0 space at 1 GB.

So, I need to change FREPTECNT into an amount used, rather than an amount left, but I don't know what to subtract from. Does anybody know what total PTE count a process starts with? I can get close by starting a process that does as little as possible. Ah, perhaps I could add the peak virtual size to it at that point. In any case, does anybody know whether this is documented anywhere? I've been looking in the system services and DCL reference manuals.

BTW, I think I can tell how many global pages are mapped by subtracting the page file in use from the total PTE's in use. Any comments or confirmation of that idea?

--Travis

[Volker Halle]

Travis,

did you try to use FREP0VA ? It gives you the first free P0 Virtual Address useable by your image to create/map pages into P0 virtual address space.

SDA> SHOW PROC/PAGE/P0 will show you all your page table entries for P0 space - but it's a lot of data...

What problem are you really trying to solve ?

Volker.

[John Gillings]

Travis,

I think you're making things far more complicated than necessary. PPGCNT is the process page count and GPGCNT is the global page count.

If the process runs a single image, VIRTPEAK should be sufficient for measuring total virtual address space, as processes very rarely delete virtual address space.

For all the gory details of memory management and address space, you probably need a copy of the Internals and Data Structures Manual.

> I can tell how many global pages are >mapped by subtracting the page file in use >from the total PTE's in use. Any comments >or confirmation of that idea?

Not true. There's no direct relationship between global pages and page file use. There are plenty of ways of having private pages that aren't backed by the page file.

Global pages are measured by GPGCNT.

[Travis Craig]

Volker,

Yes, I should have mentioned that I am looking at FREP0VA and I think it probably is a good indicator of how near my program is to disaster (inability to allocate another big chunk of virtual address space to map another global section). I am also looking at FREP1VA, APTCNT, FREPTECNT, and PAGFILCNT.

My biggest problem is that there is no warning that a process is approaching the inability to map to the next global section when it needs to. My secondary problem is to inform users of how much total address space is being used, especially in P0.

Some of my programs progressively map to more and more space and don't unmap from much of it, so FREP0VA is an excellent indicator for them. Other ones map and unmap to various sizes of global sections. In both cases, they obtain the address range to map to the global section by calling lib$get_vm. When they unmap from a global section, they map the address range back to pagefile and return the space with lib$free_vm, so FREP0VA is not a complete indication of how much space is available for future mapping to global sections. Some of the pagefile-mapped space at that point is available for mapping to global sections, if there is a large enough contiguous address range that is free. In that case FREP0VA is too conservative an indicator, because it could be up near 1 GB while most of the space is actually available in LIB$GET_VM's zone.

Thanks for mentioning the SDA command. If I need to write a monitor program that finds out the details of the available space and degree of fragmentation, it could parse the SDA output. I had been thinking I'd have to write my own kernel-mode AST routine to extract that information from a process.

--Travis

[Travis Craig]

John,

Thanks for your reply. I might be making things too complicated; I'm not sure at this point. One of my two most problematic programs often runs the scenario you mentioned, one image that mostly maps and rarely unmaps, so I pointed my user to a tool that monitors VIRTPEAK and said to watch out when it nears 2 million (1 GB) or above. VIRTPEAK includes P1 and I assume S0/S1 space, too, so it can go above 1 GB.

My other problem child does not map and stay mapped. It maps and unmaps a bunch of large and small files, in fairly random order, allowing for significant fragmentation of the address space.

My problem with PPGCNT and GPGCNT is that they monitor working set, not virtual address space. I just ran a test program to verify the document on that one. I'm hoping to stay away from the Internals and, as I mentioned to Volker, kernel-mode AST's.

I agree there is address space that is not backed by either global sections or pagefile, but I'm assuming it is relatively small for me. The other one I'd thought of was the image file itself, which backs the executable code. Your message brought to mind private sections, which I don't think I have many of, if any. Are you thinking of any others?

--Travis