Date: Tue, 30 Mar 1999 13:52:01 -0800 From: Julian Elischer <julian@whistle.com> To: Kelly Yancey <kbyanc@alcnet.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: support for larger memory Message-ID: <37014781.4487EB71@whistle.com> References: <Pine.BSF.4.05.9903301626460.12072-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kelly Yancey wrote: > > Time and time again we have all seen people get bit in the rear because > BSDI compatibility was broken. Broken for a good cause, mind you, because > FreeBSD seemed to lose a little of that "power to serve" when it died > horribly on newer servers :) > So, the good news is, we can now support large memory configurations > (and I recall that 4G might not be that far off). The bad news is, the > fairly decent number of programs which are available for BSDI but not > FreeBSD won't run on FreeBSD now. > > Anyway, we all know that. But what I would like to know is: how does > BSDI support large memory configurations? I'm confused on how it is that > the $1000+ commercial BSD derivative can't handle running on newer > servers (although it is pleasing to think a $0 BSD derivative can :) ) > Surely, this cannot be the case, though. > > So, I'm curious, why is it that we needed to break BSDI compatibility in > order to support large memory configurations. It would seem that the two > shouldn't be mutually exclusive. > > Thanks, > > Kelly > ~kbyanc@posi.net~ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message The problem is that in the default configuration the two address spaces, (kernel and user) are arranged to use non-intersecting address spaces. This allows the kernel to directly read from the user's space, and also means that the address space need not be changed when the process goes to kernel mode, saving valuable TLB flushes etc. Unfortunatly as memory has grown, the kernels 'sparse' method of allocating addresses within it's space has required more and more space to keep track of potentially larger and larger structures. Eventually the space needed grew more that that 'left over' above the user space. This required shrinking the 'address space' seen by the application program which is, unfortunatly, not completely transparent to the user application binary. One answer would be to allow the kernel space and user space to overlap. THis is what the original Unix systems did, making use of the PDP11-60's ability to hold separate address spacess for the executinve and application programs. The use of copyin() and copyout(), rather than direct copies, is both a throwback to this time, and at the same time "insurance" that BSD will be able to run pretty much without modification on architectures where such separation is mandated, or, should the situation arise, we decide to split the tow spaces, even on architectures where it is presently not done (e.g. PC). In the specific case of BSDI compatibility, I believe that there is a patch available that allows BSDI binaries to run in the smaller addres space. (I vaguely remember it involving the initial value of a register at exec time). This suggests that the BSDI runtime libraries were written with an eye to the future where they may themselves need to do a similar thing. Knowing the people involved, I'd say that this is not unlikely. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37014781.4487EB71>