Messages in this thread | | | Date | Tue, 04 Jul 2000 01:49:10 +0200 | From | Artur Skawina <> | Subject | Re: a joint letter on low latency and Linux |
| |
Albert D. Cahalan wrote: > > > Doing this (ie omitting stuff like all spinlocks, accounting etc code) > > would be fairly easy (by intelligently linking at load time), and yes, > > No, linking isn't good enough. Many of these are inline assembly. > Even when not, one would want to completely eliminate function calls.
No, "smart" linking of the kernel at boot time is enough to eliminate the useless code. For example, here is what you can do: instead of generating the spinlock code (it's an asm() anyway) you just mark the place where it would have been used (eg by placing the address in some .init section). Then the boottime "linker" (loader) can figure out whether the code is necessary (based on hw detection and/or user input) and add it. The runtime cost is just in the register allocation (any registers that are used by the inline code will be treated in the same way, even if the inline code isn't there). Yep, you have to make sure that the assembler generates relocation records even for things it thinks it knows the addresses of (which might require minor tweaks to the build tools, esp. as this should be selective in order not to penalize short branches).
> > 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) > > You aren't thinking like a distribution or hardware vendor.
Actually, like a distribution -- yes; like a driver vendor -- no, that is beyond the scope of this. See below though.
> Distributions use modules, even though compiled-in drivers are > more efficient. Until recently, distributions didn't do SMP.
Ideally, there shouldn't be any difference between a "module" and "compiled in driver", and hopefully that will be the case in the near future.
> Even if a hardware vendor ships source code, they may still want > to ship binary drivers for popular distributions. (and when they > don't also ship source, SMP users currently get left out) > > Currently we have a nasty symbol-mangling system to prevent people > from loading SMP modules into a uniprocessor kernel. This wouldn't > be so important if every uniprocessor kernel could handle the code.
So you are proposing to make the kernel less efficient so that binary only driver vendors have it easier? Because once such a "generic kernel" option is there they will use it, and then it's no longer really optional if you happen to need just one driver w/o source... I don't have anything against binary kernel modules, and i think that supporting them would be a good thing, but as a side effect of having an otherwise very useful infrastructure, not by adding unnecessary limitations.
[the scheme described above could be used to make "generic" loadable modules. It's just that it becomes quite complex, and at that point it's probably not worth it. Hence the "precompiled modules" idea mentioned in the previous message.]
> For tech support, it is nice to be able to tell someone to boot > with an option to enable lock checking or some sort of trace code. > This is easier than explaining, over the phone to someone clueless, > how to compile and/or install a new kernel.
This can already done by providing a generic for-debugging-only kernel. And some things can be enabled at runtime, eg you should be able to replace the locking code with your own versions (and back). I'm already doing this with the ip checksums, and the locking code seems even simplier -- because of the static nature and known out-of-line portions. Hmm, except the new spin_unlock() (which is just memory store, hence harder to locate).
- 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/
| |