Date: Thu, 29 Aug 2002 23:57:18 +0300 (EET DST) From: Aaro J Koskinen <akoskine@cc.helsinki.fi> To: Terry Lambert <tlambert2@mindspring.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: More dynamic KVA_SPACE Message-ID: <Pine.OSF.4.30.0208292249080.14797-100000@sirppi.helsinki.fi> In-Reply-To: <3D6E78DA.D1608F0F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Terry, On Thu, 29 Aug 2002, Terry Lambert wrote: > 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. Yes, I understand this. It seems I failed to explain what I meant. :-( The reason for moving the kernel text, data and bss to the end of the virtual memory was that this is the "not position independent" part of the kernel that would be at fixed known virtual address and always be linked and loaded correctly. What I want is to resize the KVA space without breaking the linked code. Therefore I try to organize the KVM so that the position dependant part does not move if the KVA size changes. The "dynamic" part of the KVA space would be below the kernel code, and expand towards the address 0, and this would contain all the stuff that are dimensioned according to anticipated system usage, and could be configurable by a boot parameter. E.g. if I want a lot more mbufs or kmalloc memory I could boot with a huge KVA space. My understanding is that there's lot of relevant data areas in KVM that could be dimensioned and relocated run-time in the kernel initialization. But since they are currently located above the kernel code, they will hit the ceiling at some point, unless the kernel is moved lower (KVA space expanded), which needs recompilation. > 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". But doesn't the kernel relocate some of its data in the initialization (in locore.s, pmap_bootstrap() or whatever), > As Steven Wright said "Hey! Someone has broken into our apartment, > and relaced all the furniture with exact duplicates, down to the > scratches!". (A nice analogy, very Philip K. Dickian...) > 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. The point was not to make KVA space smaller but to be able to state in the boot how many GBs the KVA should be, so that the kernel could dimension e.g. the area from which the connection data is allocated according to the KVA space limits. Surely the connection data is not position dependant or statically allocated. I'm not interested in whether it's desirable or not to have huge KVA or UVA space; I'm interested just in the problem of moving this decision from compile-time to run-time. A. -- Aaro Koskinen E-mail: aaro@iki.fi "I'm the ocean, I'm the giant undertow." http://www.iki.fi/aaro 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?Pine.OSF.4.30.0208292249080.14797-100000>