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/