lkml.org 
[lkml]   [1999]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support


On Fri, 10 Dec 1999, Pavel Machek wrote:
>
> That is bad idea. You want (to be able to) compile 386 kernel with
> fastcall ability when ran on PII. (That's the one RedHat is going to
> ship, you know?)

Well, more importantly, I _still_ think that if we add a new way of doing
system calls, we ALSO have to add a new way to have a unified calling
convention.

We should NOT say "you can now do system calls fifteen different ways,
please try to find out which one is best for you".

We SHOULD say "ok, we have ONE new way of making system calls, and the
kernel will just use the fastest way that works on this CPU".

This is not only an issue of good taste and sane interfaces. It is also an
issue of long-term maintenance. Anybody can add new features - just look
at what happened to DOS->Win1->Win2->Win3->Win31->Win95->Win98->...

We want to AVOID that kind of chaos - we do not want to have different
ways of doing the same things that offer slight advantages over each over.

In short, it is NOT WORTH IT to speed up system calls by 150 cycles unless
it's a clean and good interface. People should wake up to the realitites
here: most system calls take on the order of thousands of cycles, and the
benchmarks that have been quoted in this discussion are mostly completely
and utterly irrelevant to ANYTHING.

Who cares how fast you can do "getpid()"? NOBODY. It's meaningless.

Guys, this is final. Look at the bigger picture, instead of being
enamoured with a cool feature.

If you want to speed up a system call, make the ONE system call you
concentrate on be "gettimeofday()". And realize that you don't even have
to switch protection domains to do it - the fastest speedup of
gettimeofday() is not to use "SYSENTER" instead of "int 0x80", but to get
rid of the system call completely.

I've already outlined one way of doing it so that the client program
doesn't even need to care about whether SYSENTER exists, or whether the
CPU has a TSC, or whether the TSC keeps constant time or dynamically
switched. If people don't like that, then argue about better ways.

In short, arguing for a SYSENTER-only solution is stupid (because it is
provably not the fastest solution =anyway= - I've given you one example,
and I bet people can find others) and unproductive if you want it in the
standard kernel (because I won't be applying any such patches simply
because I know that it is fundamentally the wrong thing to do).

So stop looking at details, and look at the REAL problem instead.
Technology is uninteresting if it doesn't solve the right problem.

For example, all this discussion about which system calls can be done with
SYSENTER, and which ones cannot is just looking at things the wrong way,
and should have convinced people that it is not a choice we should even
make user space AWARE of. Because the issue does not make any sense on a
user space level - the whole approach is wrong if this becomes a ABI
issue.

Instead, we should just have different classes of system calls:
- system calls that return errno are one subclass, because they obviously
need to interact with libc in non-kernel ways.
- system calls with different numbers of arguments might be different
classes. Note the MIGHT. Using the same stub for them all
hasadvantages: even if it means an extra instruction or two for the
really simply case, the icache footprint advantage may actually make it
the faster case, even if you'll never see it in synthetic benchmarks
that don't do any real work.
- gettimeofday() is a special class (we know why). For implementation
reasons, we probably want to have certain other "fundamental system
calls" in their own classes - things like "clone()" and "execve()" are
just so fundamentally different from other calls that it makes sense to
consider them separate things, for example. ptrace and sigreturn
similarly interact with internal kernel state and might be special.
- other classes?

And then we just export some sane way of doing all these different classes
of system calls WITHOUT having to have the user level care about
differences that should not be visible to user space. And in ways that
work regardless of what the underlying CPU is.

If people don't like the page mapping idea, then come up with a better
way, but don't beat the dead horse of exposing SYSENTER.

Linus


-
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/

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