Messages in this thread | | | Date | Mon, 03 Jul 2000 06:55:37 +0200 | From | Artur Skawina <> | Subject | Re: a joint letter on low latency and Linux |
| |
Albert D. Cahalan wrote: > > Digital UNIX (now Tru64, was OSF/1) uses self-modifying code to > create a generic kernel that can do, if I remember right: > > 1. plain > 2. real-time > 3. SMP > 4. real-time SMP > 5. lock debugging > > So, if you don't want these features, you only suffer some NOPs and > perhaps sub-optimal register allocation. I suppose the x86 version > of this could be a debug breakpoint byte followed by a byte to indicate > the required operation -- lock, unlock, or whatever. One might also > be able to make the assembler spit out addresses, like the exception > table code does. > > Other uses for this technique include: Generic kernels could run > on a real i386 without being slow on a 486. Modules could work for > SMP, huge memory, and normal kernels. Exact process accounting could > be part of every kernel, but NOPed out at runtime if not enabled.
Doing this (ie omitting stuff like all spinlocks, accounting etc code) would be fairly easy (by intelligently linking at load time), and yes, the price would be in register allocation. But what about data structures?.. Either you'd have to leave them alone, in which case the "generic" kernel would eg be faster on UP than on MP, but would still not be as efficient as a dedicated UP one; or you could fix up all references, but then this becomes much too complicated. At that point I'd prefer to simply have a two+ stage boot process where the final kernel is recompiled (possibly from some kind of precompiled form to speed this up) to match the hardware. Or you could have all possible versions of the code prebuilt and link only the required objects on boot.
IOW, making a generic kernel a bit more efficient when certain features aren't needed is possible, but the price isn't only worse register allcation. (yep, some things can be done at runtime, but the only feature from the above list i can see this making sense for is bypassing the rt layer when it's not in use)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |