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