* H. Peter Anvin <[email protected]> wrote:
> It seems that you're doing the same thing in both cases, except you're
> now extending it to include other random functionality, which means
> other things than syslets are suddenly affected.
>
> syslets are arguably a little bit different, since what you're
> effectively doing there is running a miniature interpreted language in
> kernel space. A higher startup overhead should be acceptable, since
> you're amortizing it over a larger number of calls. Extending that
> mechanism suddenly means you HAVE to use that interpreted language
> message mechanism to access certain system calls, which really does
> not seem like a good thing neither for performance nor for encouraging
> sane design of interfaces.
whether that interpreted syslet language survives is still an open
question - it was extremely ugly when i wrote the first version of it
and it only got uglier since then :-)
do you suggest that extending the system call calling convention to
include an arbitrary number of parameters will solve all these API needs
we have at the moment?
if yes, then a one-shot syslet/async call would in essence be:
syslet_arg1 ... N, syscall_arg 1 ... M
the same is true for the indirect stuff, we in essence nest syscalls
inside another syscall:
sys_indirect arg1 ... N, syscall arg 1 ... M
this all assumes an arbitrarily extendable syscall ABI, which can take
N+M parameters. Right?
i'm not entirely sure we really want to do this. Nested syscalls would
have to unpack the arguments and repack them into a kernel-internal call
format anyway. So there's no performance upside - in fact i can only see
additional complications.
Why not just pin down the current ABI that there's 6 syscall parameters
_and not more_? It's totally sensible, and indirection has some minimal
costs anyway, so copying the nested syscall parameters is a non-issue.
This is not ad-hoc and when i wrote syslets i actually profiled the
performance a variable-length calling convention and decided _against_
it. Nothing beats the performance of a straight fixd-length copy of 6x4
(or 6x8) bytes.
The memory access cost argument you mentioned is largely irrelevant and
inapposite here, this is all passed in on the stack which is well-cached
in the L1 cache.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
