kka059@MIPL3.JPL.NASA.GOV (02/10/88)
Here's the second attempt to get this up onto the net: Has anybody out there observed anything similar to the following condition: 1) $CRMPSC a disk file section (in our case it's about 12000 blocks in size) [the available PTE count (watched with SDA) drops by about 12000 blocks], 2) Use the section for a little while, 3) $DELTVA the section to release the virtual memory, but the available PTE count does *not* go back up! This is an intermittant problem which, when it strikes, causes the progam to eventually die with a SYSTEM-F-VASFULL error, since the program eventually tries to map in 48000 pages of disk file sections against a VIRTPAGCNT of 50000. If the process page table thinks that it has one or two extra 12000 pages pieces of disk file section(s), this exceeds the VIRTPAGCNT by at least 10000 pages. If anyone has any suggestions or has observed this themselves, please let me know. P.S. We're still running VMS 4.4 :-( +----------------------------+------------------------------------------+ | Kurt Andersen | Jet Propulsion Laboratory | | MIPL Applications | Mail Stop 168-427 | | Software Engineer | 4800 Oak Grove Drive | | Office: 169-425 | Pasadena, Calif. 91109 | +----------------------------+-------------------------+----------------+ | NETWORKS: | | | SPAN: Mipl3::KKA059 (5.153) | Does the verb | | ARPA Internet: KKA059@Mipl3.Jpl.Nasa.Gov | `to flame' | | Internet Address: [128.149.1.28] | come from the | | ARPAnet->SPAN: KKA059%Mipl3@Star.Stanford.Edu | days of the | | or: KKA059%Mipl3.Span@Jpl-Vlsi.Arpa | Inquisition? | | Ma Bell (R.I.P.): (818) 354-1672 | | +------------------------------------------------------+----------------+
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (02/17/88)
1) $CRMPSC a disk file section (in our case it's about 12000 blocks in size) [the available PTE count (watched with SDA) drops by about 12000 blocks], 2) Use the section for a little while, 3) $DELTVA the section to release the virtual memory, but the available PTE count does *not* go back up! This is an intermittant problem which, when it strikes, causes the progam to eventually die with a SYSTEM-F-VASFULL error, since the program eventually tries to map in 48000 pages of disk file sections against a VIRTPAGCNT of 50000. If the process page table thinks that it has one or two extra 12000 pages pieces of disk file section(s), this exceeds the VIRTPAGCNT by at least 10000 pages. Are these writable sections? Getting rid of a large, writeable section can take quite some time (many seconds) - what VMS does is dump all the modified pages onto the modified page list, then kick the modified page writer. The modified page writer will write out EVERYTHING on the modified page list. Not until it's finished with that will the section really be freed up. (This same factor can cause very slow screen updates - "tiling" - on GPX's, BTW. It's a recognized limitation of the current implementation of the VMS file section flushing algorithms. Not that $UPDSEC does the same thing - you don't actually have to unmap the section.) The only work-around I can think of is to have your code check the error return from $CRMPSC and, if it's VASFULL, try again every again. Trying every second for perhaps 20 seconds should do it.... -- Jerry
mike@VAX.OIT.UDEL.EDU ("Michael J. Porter") (02/18/88)
>From: MAILER!<local-info-vax-request@louie.udel.edu> 17-FEB-1988 04:24 >To: info-vax%kl.sri.com@UDEL.EDU >Subj: Process Page Table Quota Errors > >Date: Tue, 9 Feb 88 19:10:33 PST >From: kka059%mipl3.jpl.nasa.gov@UDEL.EDU >Message-Id: <880209191033.00h@Mipl3.JPL.Nasa.Gov> >Subject: Process Page Table Quota Errors >To: info-vax%kl.sri.com@UDEL.EDU >X-ST-Vmsmail-To: ST%"info-vax@kl.sri.com" >Here's the second attempt to get this up onto the net: > > > Has anybody out there observed anything similar to the following condition: > >1) $CRMPSC a disk file section (in our case it's about 12000 blocks in size) > [the available PTE count (watched with SDA) drops by about 12000 > blocks], > >2) Use the section for a little while, > >3) $DELTVA the section to release the virtual memory, but the available PTE > count does *not* go back up! > >This is an intermittant problem which, when it strikes, causes the progam >to eventually die with a SYSTEM-F-VASFULL error, since the program eventually >tries to map in 48000 pages of disk file sections against a VIRTPAGCNT of >50000. If the process page table thinks that it has one or two extra 12000 >pages pieces of disk file section(s), this exceeds the VIRTPAGCNT by at >least 10000 pages. > >... I had a similar problem and found it necessary to pre-allocate enough pages for LIB$GET_VM (using the code below) and specifying that RMS get its buffers from P1 space. What happened was that either LIB$GET_VM or RMS would allocate pages after I mapped the section. When I tried to delete the virtual pages, VMS would not contract the address space for the process unless all pages from the high end of P0 space were to be deleted, ie: you can't make a 'hole' in the P0 address space. The following will allocate RMS buffers and keep them in P1 space. This line is added to a linker OPTIONS file. Note that you have to allocate a large enough section or else RMS will run out of space. Since the stack is also in P1 space and must be contingous, RMS has no place to get more memory. IOSEGMENT=1024,NOP0BUFS The following is the BLISS code fragment I use to get a large chunk of VM before I map any sections. Note that FREE_VM_PAGE does not release it from the process, it just allows LIB$GET_VM to use it. !+ ! Call the VM page routine to grab as much memory as we need for ! the default zone, then release the pages. If this is not done, ! P0 pages might be allocated after we map a DVI file, which would ! prevent the address space from contracting after we closed the ! DVI file. Make several calls because get_vm_page does not like ! to handle large amounts of pages at a time. !- INCR i FROM 0 TO 3 BY 1 DO BEGIN ret_status = LIB$GET_VM_PAGE( %REF( 256 ), temp[ .i ] ); IF NOT .ret_status THEN LIB$STOP( .ret_status ); END; INCR i FROM 0 TO 3 BY 1 DO BEGIN ret_status = LIB$FREE_VM_PAGE( %REF( 256 ), temp[ .i ] ); IF NOT .ret_status THEN LIB$STOP( .ret_status ); END; (Interesting, when I copied the above code fragment out, I found a longstanding error. The free call was only releasing 128 pages instead of 256 as was allocated.) ================================================================================ Michael Porter Systems Programmer Univeristy of Delaware Newark, DE 19716 Phone: (302) 451-6040 Internet: mike@vax.oit.udel.edu ------