System V.2 and growing processes

[Paul De Bra]

In article <6936 at june.cs.washington.edu> ka at june.cs.washington.edu (Kenneth Almquist) writes:
}mike at 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 at research.att.com   | uunet!research!debra     |
------------------------------------------------------