> > > still means that the amount of time we spend in '1' and '2' is O(n). While
> > > each call to poll takes O(n) time, it returns O(n) ready file descriptors.
> > > Overall, poll is O(1) for high-load applications.
> >
> > Oh dear. Tell you what. You go write an http accelerator thats faster than
> > phttpd then come back
>
> Alan, you are being too flip. I'll give you an example of an existing
> server you use every day heavily that exploits this behavior, deliberately (and
> has for nearly 15 years).
>
> This principle is why X works well under load (actually, will work alot
> better interactively in XFree86 4.0 due to recent X dispatcher changes
> Keith Packard has made): in fact, in X, you get WAY under one system call
> per operation (or even client with requests to process), do to a combination
> of batching requests, and this behavior of select.
Right, but you're not testing the entire overhead (including kernel-space
time) of the syscall, are you? You're assuming more syscalls == slower.
What if you could have one syscall that would fill out a maximum of x
event structures for you and return how many it actually filled out? You
could completely avoid the process of constructing and scanning the
select sets in userspace, and the same for the kernel. The kernel
wouldn't have to poll anything, because it would already be queued up
when an event occurs.
This has got to be faster than using select(), no? There is no wasted
time testing filedescriptors for events and scanning lists, you just tell
the kernel to fill out a set of preallocated structures with event data
that it already has available.
Simon-
[ Stormix Technologies Inc. ][ NetNation Communcations Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
-
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/