Innes Read wrote: >All of which makes me wonder what the underlying technical reasons and >thinking were, there's normally a valid reason behind seemingly odd >decisions like 'lets stick this stuff right in the middle where it'll >really get in the way'!
The original reason behind the Linux memory layout was that you have *three* memory regions that can potentially grow independently of each other: the main executable including its brk() heap, memory mapped files (including shared libraries), and the main stack. Ideally, you want to allow each of the three areas to grow 'big' without getting in conflict with the other two, without manual intervention. Thus, it was thought the best solution would be to place the three areas as far apart from each other as possible: at the bottom, the middle, and the top of the address space. At that time the assumption was that 'big' meant maybe on the order of 100 MB, but nowhere near the size of the address space. This worked pretty well until the time arrived where 'big' now means 'the full address space, or at least the largest possible chunk of it'. (IMHO what this *really* means is: my address space is too small, I want 64 bit ...) Thus, people have been looking for various solutions to try to optimize the address space under these new conditions. One way is the /proc/.../mapped_base mechanism that Red Hat introduced with AS 2.1, and which is now present in SLES8 as well. (It is not part of any standard Linux kernel.) The very latest attempt (again introduced by Red Hat, but not yet in their RHEL3) is to give up the notion that all three areas are equally likely to grow big, and limit the stack growth. This means that the maximum stack size is fixed at program start (depending on the stack rlimit), and memory mapped files are placed from the bottom of the stack on downwards. There is currently discussion ongoing whether to add this logic to the standard kernel. In any case, it is not present in any distribution currently available for zSeries ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED] ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
