Dean Gaudet wrote:
>
> where's ingo? shouldn't he be jumping in here telling us syscall overhead
> is some impressively tiny number of cycles which is bare noise above the
> L1/L2 cache sloshing we'll see at scale? :) after all, we're talking
fwiw here int80 syscall overhead is ~298 cycles (that's getpid latency),
sysenter reduces it by ~130 cycles.
> about servers with 4k+ sockets, and alan cox tells us to budget about 23kb
> of memory per socket -- that's almost 100Mb of RAM... makes me wonder if
> combining syscalls is worth the complexity.
it isn't. at least not for uncommon ones like accept/close; if the
few hundred cycles make a real difference you have other problems
anyway. [ignoring benchmark #s]
> out of curiosity, has the fast syscall and fast gettimeofday stuff with
> the nifty kernel-supplied code page made it into the kernel/glibc/etc?
not that i know of. it's not trivial stuff; you'll probably end up
redesigning a large part of the current syscall code (if it's to be
reasonably clean). i actually now have both sysenter and the magic
sysentry page in this kernel, but i haven't merged them together
yet :) (various reasons, like: it's not 2.4 stuff, i was kind of hoping
the people who were mentioning amd syscall would produce something too
(so i could be sure the abi worked for them too), there are a few unsolved
issues etc.).
-
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:32 EST