lkml.org 
[lkml]   [1998]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.038 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site