Messages in this thread | | | From | "Adam J. Richter" <> | Date | Sun, 24 May 1998 19:39:59 -0700 | Subject | Re: Modularized x86 math emulation PATCH against pre-2.1.104-1 |
| |
Michael Chastain <mailto:mec@shout.net> writes: >In arch/i386/config.in, your patch redefines the default processor type >from Pentium to 386 -- this looks gratuitous.
You're right. That was an accident. We build our kernels here for 386 so that they will run on all x86 micprocessors, including ones that do not have a bswap instruction. I failed to filter out that difference.
>I'm more concerned about the use of CONFIG_MATH_EMULATION_MODULE in >arch/i386/kernel/traps.c. I think that math_emulate_hook is fine. >But I think that it's bad to make the resident kernel be different >depending on whether or not a particular module is compiled. So I >recommend taking out these tests and compiling in math_emulate_hook >and the new code in math_emulate unconditionally.
Rather than using words like "good" or "bad", if you state your concerns in terms of cause and effect, and let the goodness or badness of those effects speak for themselves, people who read your posting will better understand the dynamics of the problem your are describing.
By using CONFIG_MATH_EMULATION_MODULE, I was able to ensure that if this patch is integrated into the kernel, users who choose not to modularize the math emulation will not lose a single CPU cycle to accomodate the math being available as a loadable module. Speed tends to be a particularly important metric for math, even software math emulation on a 386, unlike, say, with the code Advanced Power Management or control of the keyboard lights.
If your concern is about maintainability, I disagree and I agree. I disagree that the selection of modular math emulation makes the code so different when one is writing source code. The semantics of the three interface routines that talk to the math emulation (math_emulate, {save,restore}_i387_soft) are unchanged. Hook variables are a popular easily understood programming technique, and the concept of replacing these hook variables with direct references to their corresponding routines when those routines are being compiled in is also a commonly practiced optimization technique.
So, I think the relatively small complexity increase is worth the benefit to users who really want FPU emulation to go fast (probably people running donated used computers in school, or trying to build minimum cost embedded devices). After all, in the case of math_emulate, we're talking about something that gets executed on every floating point instruction. There is actually some further optimization to the code path to math_emulate that I was thinking of doing, that would make it more consistent with the way {save,restore}_i387_state works, by the way.
On the other hand, I do agree with the objective of basically having just one kernel for ordinary situations. As you may recall, we have that here. We have a "./configure" script in the kernel that basically modularizes everything that can be modularized, answers "yes" to all boolean questions and takes the default values for everything else, with a few special cases. This is how I think most people should build the Linux kernel, "./confiugre ; make all ; make install", just like most other pieces of free software. (The install builds an initial ramdisk that does Plug'n'Play hardware probes to mount the root partition.) Ultimately, I think "make config", and "make xconfig" will, for most users, will fade into obscurity. At that point, it might make sense to look at the kernel and consider deleting most of the infrastructure for having most kernel modules "compiled in", because then the memory savings, minor additional performance benefits and much bigger code simplication benefits will probably outweigh this optimization to the code path for math emulation; it may even be a win on performance alone at that point.
I do not actually feel that strongly about this issue, especially if I do fix the code path for math_emulate() in he modularized case. I'd be happy to see modularized math emulation integrated into the main kernel distribution or on vger or anywhere else in either form.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |