Messages in this thread |  | | | Date | Sat, 11 Dec 1999 22:24:43 +0100 | | From | Artur Skawina <> | | Subject | Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support |
| |
Linus Torvalds wrote: > > 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
Note that, while i may have indirectly brought this issue up, never expected that anybody would consider this something that could be quickly implemented, without considering the consequences. However that did happen, and once the seriously broken patches were being posted, and boldly declared as fully functional complete implementations, I got worried for a while... The system call i/f, being probably the most important kernel one, is not something you can redesign once you realize it's broken.
> Who cares how fast you can do "getpid()"? NOBODY. It's meaningless.
In this case i'm quite sure everybody was using it only because it's the fastest syscall around and its static nature makes it a perfect testcase.
> concentrate on be "gettimeofday()". And realize that you don't even have > to switch protection domains
exactly.
> I won't be applying any such patches simply > because I know that it is fundamentally the wrong thing to do).
phew. Actually the last few days convinced me there's no other way than the blackbox solution. It might loose a few cycles, but i prefer that to the support nightmare i for a while suspected linux was heading towards.
> So stop looking at details, and look at the REAL problem instead.
well, i wouldn't put it that way, looking at the details isn't bad in itself; in fact it can help a lot when designing interfaces, and certainly never hurts. Not loosing sight of the bigger issue is what's required.
> 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.
i think there's some potential for libc<>kernel cooperation, many of the libc stubs are very similar and might benefit from a bit more kernel help. (prpbably nothing more than making sure these two do not needlessly get in the way of eachover)
> - 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.
hmm, a few classes could work (eg 0-2/3-6args), but this depends on a _lot_ of factors (aot which of the critical entries are specialcased, whether the _internal_ handling can benefit,...)
> - 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.
ptrace is worth seriously looking at. Signal handling can be made to work with almost any scheme, but ptrace is special. it alone probably accounts for a ~10% overhead, maybe more, even when it is _not_ used at all. for example it would be relativly trivial to speed up the fast path by the number above, while slowing down ptrace (it has so much overhead anyway that it wouldn't matter in RL). Hmm, one could think of keeping a count of all ptrace usage in the system, so that during normal operation, when nothing is being debugged, things would go a lot faster.
> - other classes?
maybe. maybe some calls that are sufficiently special, but not critical to performance can be moved away from the "normal" path, if that makes it go faster (like iopl, execve, vm86)
> 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.
it's important to get this right the first time though.
> If people don't like the page mapping idea, then come up with a better
As i said above I now think that's the only available solution. Not so much because of any technical reasons; i'm afraid the development model forces this. And this is one of few areas where having several independent (potentially conflicting) solutions would really hurt. Does anybody work (or plans to in the near future) on this?
- 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/
|  |