Messages in this thread | | | Date | Wed, 23 Feb 2000 02:51:23 +0100 | From | Artur Skawina <> | Subject | Re: accept() improvements for rt signals |
| |
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/
| |