Xref: utzoo comp.unix.internals:823 comp.lang.c:33146
Path: utzoo!attcan!uunet!know!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals,comp.lang.c
Subject: Re: Can I minimize expansion swaps?
Message-ID: <18644@rpp386.cactus.org>
Date: 25 Oct 90 12:51:43 GMT
References: <1990Oct24.215412.5192@gtisqr.uucp>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Distribution: na
Organization: Lone Star Cafe and BBS Service
Lines: 33
X-Clever-Slogan: Recycle or Die.

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