Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 12 Nov 2003 16:32:55 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: So, Poll is not scalable... what to do? |
| |
On 12 Nov 2003, bill davidsen wrote:
> In article <20031112053207.GA9634@alpha.home.local>, > Willy Tarreau <willy@w.ods.org> wrote: > | On Tue, Nov 11, 2003 at 05:52:42PM -0600, kirk bae wrote: > | > If poll is not scalable, which method should I use when writing > | > multithreaded socket server? > | > | Honnestly, if you're using threads (I mean lots of threads, such as one > | per connection), I don't think that poll performance will be your worst > | ennemy. The first thing to do is to handle the task switching yourself > | either with a publicly available coroutine library or with one of your own. > > It's not clear that with 2.6 this is necessary or desirable. I'll let > someone who worked on the new thread and/or futex development say more > if they will, but I'm reasonable convinced that in most cases the kernel > will do it better.
Pros & Cons:
*) Coroutines cost is basically its stack (8-16Kb). Threads there's a little bit more under the hood
*) No locks at all with coroutines
*) Coroutine context switch time was about 20 times faster last time I tried. I used this:
http://www.xmailserver.org/libpcl.html
against O(1)
*) Coroutines require a more careful coding then threads, expecially stackwise
*) Achieving SMP scalability/balancing with coroutines is not trivial while with threads it comes along (well, almost)
Coroutines are not the only alternative though. I/O driven state machines can make you save some stack space at expenses of less trivial coding.
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |