Date: Thu, 29 Aug 2002 12:41:14 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Aaro J Koskinen <akoskine@cc.helsinki.fi> Cc: freebsd-hackers@freebsd.org Subject: Re: More dynamic KVA_SPACE Message-ID: <3D6E78DA.D1608F0F@mindspring.com> References: <Pine.OSF.4.30.0208291600300.303-100000@sirppi.helsinki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
Aaro J Koskinen wrote: > I've been thinking what kind of modifications would it need to decide > the KVA space size at the kernel boot time (maybe an argument to > btext), instead of compile time. In theory I can't see any obstacles. > > Basically the approach would be simply the following: [ ... approach ... ] > Am I completely off the track? What are the main reasons behind the > current KVM layout? Kernel code is not position independent. The way protected mode OSs work, in the simplest terms, is by crafting a KVA space that looks exactly like the physical space after the bootstrap load, so that none of the code needs to be relocated, and it all "just works". As Steven Wright said "Hey! Someone has broken into our apartment, and relaced all the furniture with exact duplicates, down to the scratches!". That's what a protected mode OS does between the time it is loaded and is jumped to by the bootstrap, and the time that it runs in the KVA space, with paging enabled. It's theoretically possible to do what you want, but it's not very easy, and there are other reasons it's not desirable. The number one reason that it's not desirable is that you would not have any additional memory available for kernel modules or kernel data structures. For example, if you wanted to have a very large number of network connections on a 4G machine, the practical limit that you will run into is the KVA space available for representation of connection data. I've personally run a FreeBSD 4.2/3 machine up to 1.6 million simultaneous connections. In order to do this, I had to fix a couple of bugs (e.g. use of a short for credential reference counts, etc.), and move to a 3G KVA space -- make the KVA space *larger*, not smaller. On a tuned stock 4.6 kernel, you can get to about one eighth that many connectsions (~200,000 simultaneous), but you will still need to increase the KVA space to 3G as part of your tuning. You can up this number considerably (and hit the 1,000,000 mark) by patching the kernel to tune certain values individually which are currently "gang-tuned". Just *mapping* 3G of KVA space will take you an incredible amount of memory, and no matter what you are doing, you can't really steal from the KVA to give to the user space, and expect to be able to do a lot of work, easily. If you need a larger amount of UVA space, you might want to consider buying an IA64 machine, instead, since the bigger your iron, the bigger your KVA space requirements will be. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D6E78DA.D1608F0F>