pung@ornl-knsms ("M. S. Pung") (07/14/88)
Original Message: > According to what I've been told at one VAX/VMS performance seminar, it > does not make sense to define a large MPW_HILIMIT. The reason is that whenever > a process with pages in the modified list terminates, the whole list is > written to disk, so its size gets down to zero. That's probably why it can > never grow really big. Frank Nagy's response: >> This is 95+% wrong! When an image exits, most of its modified pages are >> flushed to the free list since they have NOWHERE to go on the disk. The >> only modified pages written back to disk are those from files mapped as >> writable sections. In .EXE files, the code is read-only (99%) and so >> become RO pages which are flushed to the free list on termination. >> Initialized variables are usually in Copy-On-Reference sections and >> unitialized variables (and ones inited to 0) in Demand-Zero sections; >> in both these cases the page in memory DOES NOT get written back to the >> .EXE file but has the system paging files as their backing store. When >> the image exits it makes no sense (and so VMS does not do it) to write >> these pages to the paging file. One comment concerning Frank's response is to note that the ALL-IN-1 product DOES use global sections and thus each time an ALL-IN-1 user's process terminates the Modified Page List (MPL) is flushed (i.e. ALL pages are written, not just down to MPW_LOLIMIT). So if your are running ALL-IN-1 and you have a large MPL, then you may see pauses in the system as the Modified Page Writer is busy clearing the MPL. In this case, it would be better to set a moderate to small MPL and set up large user working sets. Comments ?? |------------------------------------------------------------------| | Mike Pung | (615) 574-8082 | | Oak Ridge National Lab | Pung%ornl-knsms@ornl-msr.arpa | | Martin Marietta Energy Systems | 128.219.128.10 | |------------------------------------------------------------------| ------