roger@gtisqr.uucp (Roger Droz) (10/25/90)
I have two programs that run well at work on a system V with paged virtual memory and run poorly at home on a system 3 derived Xenix with swapping style virtual memory. I believe the performance difference to be related to "expansion swaps", where Xenix must write the whole data segment of the process to the swap device whenever the process size must be increased by an mmu increment. (4K on my Tandy 6000.) Both programs grind to a snail's pace when reading in files which will be broken into chunks and stored in malloced memory. In both cases, the size of the file is a reasonable approximation of the total amount of memory required. (One of the programs is MicroEMACS, in case a specific example is useful in answering this question.) Possible solution: if ((ptr = malloc(<size of file>) != NULL) free(ptr); else /* error */ The intention is to warn the operating system that the program will eventually need <size of file> bytes, then free the memory. The program will then allocate at least <size of file> bytes piecemeal as the input file is parsed. This solution won't work if free() is smart enough to shrink the process when a block of memory adjacent to the end of the data segment is freed. The size of the file is a conservative estimate, so another expansion swap may be necessary to complete the process of loading the file, but performance is improved over doing an expansion swap every 4K. Often too much memory will be allocated. Some of the memory needed may already be in the heap due to previous calls to free(). What I am really trying to ask for is <size of file> bytes of not necessarily contiguous memory as an approximation of the eventual requirements of the program. The sole purpose for doing this is to permit the system to optimize the expansion of the process. My thanks to any wizard who takes the time to offer advice. Please email your response, as our newsfeed is flakey. Post your response, if you think this is a question of general interest. ____________ Roger Droz UUCP: uw-beaver!gtisqr!roger () () Maverick MICRoSystems / Global Technology International (_______) Mukilteo, WA ( ) | | Disclaimer: "We're all mavericks here: | | Each of us has our own opinions, (___) and the company has yet different ones!"
jfh@rpp386.cactus.org (John F. Haugh II) (10/25/90)
In article <1990Oct24.215412.5192@gtisqr.uucp> roger@gtisqr.uucp (Roger Droz) writes: >I have two programs that run well at work on a system V with paged >virtual memory and run poorly at home on a system 3 derived Xenix with >swapping style virtual memory. I believe the performance difference to >be related to "expansion swaps", where Xenix must write the whole data >segment of the process to the swap device whenever the process size must >be increased by an mmu increment. (4K on my Tandy 6000.) The system will only swap a process while growing the data segment if there is insufficient physical memory to hold the new process free at the moment. A request is made for a memory region large enough to hold the new data segment, and if it fails, the process is swapped out until malloc is able to satisfy the request. The problem is that the code does not check for adjacent physical pages, so the only option is swap, and since the Tandy 6000 only supports 1MB or so of physical memory, running out is easy. malloc()'ing the memory in advance will give you one big swap. The only thing is to do it close to where the memory is needed so you don't have all that physical memory tied up and force other processes to swap. This same trick works with streaming tape drivers which require large amounts of physical memory for buffering. Write a command which does a giant malloc, fondles all the pages, and then exits. Now, restart your streaming tape application and it should work just fine. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson