Re: So, Poll is not scalable... what to do?

[Davide Libenzi]

On 12 Nov 2003, bill davidsen wrote:

> In article <20031112053207.GA9634@xxxxxxxxxxxxxxxx>,
> Willy Tarreau  <willy@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/