Messages in this thread | | | Date | Fri, 26 Jun 1998 23:41:13 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
MOLNAR Ingo writes: > > On Fri, 26 Jun 1998, Richard Gooch wrote: > > > > it might be that the implementation does not scale well. Unless there is > > > something fundamentally broken about the aio_...() interface (API) itself, > > > why reimplement the wheel? It's a standard interface. > > > > OK, fine. Under Linux (and possibly other OSes) that implement aio_*() > > using threads, it does not scale very well. [...] > > the _current_ implementation. There is nothing that says you cannot > implement aio_*() with a pool of threads and your 'slice up the select > space into small pieces and make pieces migrate to get better balance' > concept ...
How do you slice this up in the face of blocking file I/O? Once a thread starts a read on a regular file, there it sits. I suppose you could resort to trickery and fstat(2) FDs and if they are sockets, use poll(2) as the basis for dispatching to a smaller number of threads. But then you're back to the scheme I'm proposing, in essence, just with another layer of code (bloat) on top.
> i was just suggesting this, nothing else. Please use an existing interface > (unless that interface is broken). Especially as the hard work of > integrating it and getting it to work has already been done ...
That is what I favour: using the existing interface (poll(2) and pthreads) in a clever way such that it scales with many open connections. Also that select(2) and poll(2) should be further optimised (about 3x is what I can deliver). I hope these changes will provide us with a scalable interface. However, if this doesn't turn out to be the case, we should then look at alternatives (such as "readiness event" queues in the kernel), or some alternative user-space solution that *does scale*.
> your migrating fd scheme does seem to fit well into the aio_*() API at > first sight. [same is true for the fcntl() driven RT signal stuff]
Yes, but see above. For HTTP servers, a migrating FD scheme for an event management abstraction may serve better. Also, since various OSes will implement aio_*() using threads, and assuming they don't do clever migrating FD tricks for sockets, this will not serve well for applications which want to be portable (and still retain reasonable performance).
The fcntl(2) driven RT signal stuff also looks good, except that it's non-portable.
I want to emphasise this point: I want to provide a scalable, portable solution. If I can do something that will make a HTTP server run faster on any UNIX with pthreads, this is far better than just hacking Linux to boost HTTP performance.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |