Messages in this thread | | | Date | Sat, 11 Dec 1999 12:14:09 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [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/
| |