Path: utzoo!attcan!uunet!lll-winken!ames!killer!texbell!bellcore!faline!thumper!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.wizards
Subject: Re: System V.2 and growing processes
Keywords: swapping
Message-ID: <8745@alice.UUCP>
Date: 13 Jan 89 15:32:55 GMT
References: <627@cimcor.mn.org> <6936@june.cs.washington.edu>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 32

In article <6936@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes:
}mike@cimcor.mn.org (Michael Grenier) writes:
}> My Microport V/AT box has a very very slow brk/sbrk call. It seems that
}> when a process wants to increase its brk value, the entire process must
}> be moved in memory or out to swap space EVEN when there is available
}> and contigous memory right next to (at higher addresses) the growing process.
}>
}> Is this normal behavior for a System V.2 kernel?
}
}This approach is the one that is used on the PDP-11.  It works reasonably
}well on the PDP-11 because processes are limited to 64K of data on that
}machine.  In the PDP-11 scheme the data area (which grows up) is stored
}below the stack (which grows down), so when either the stack or the data
}area is grown, the process must be moved, even if there is contiguous
}memory right next to the growing process.  When UNIX was ported to the VAX,
}a different scheme was implemented.  Processes are not stored contiguously
}in memory.  Instead, the pages of a process are scattered throughout memory.
}Thus the problem you describe does not occur on VAX.
>...

Aha, this may explain why SCO Xenix 286 does not have the same problem
Microport has: in SCO Xenix the stack doesn't grow at all. When you compile
(actually link) a program you tell the linker how much stack-space to
allocate. So the stack can be below the data, avoiding the problems of
growing processes. Of course having a fixed-size stack sometimes is a
problem by itself... (like try to write alloca:-(...)

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------