On Dec 23, 1:09pm, Dan Melomedman wrote:
> Subject: Different select/poll implementations
> This has probably slipped someone's mind before,
> but I still would like to ask
> if state-threads will also support more scalable implementations like
> Niels Provos' /dev/poll and FreeBSD's kqueues in the future?
I think that the performance impact of different poll() implementations
is somewhat overrated by kernel people.
In the ST architecture poll() or select() is only called in the idle
state when the run queue is exhausted and there is nothing more to do.
In the "busy" case when we have many active file descriptors, the run
queue becomes very long (many runnable threads) and poll()/select()
calls are relatively infrequent (even less frequent than once per second,
as it was during our SPECweb benchmarking tests). In this situation
reducing the polling time even to zero won't improve the throughput by much.
In the "slow" case when we have many file descriptors but only few of
them are active, the polling time is the same as in the "busy" case but
the run queue is short and poll()/select() calls _are_ frequent.
The system should be mostly idle, however, because only few threads are
active. Thus response times are still much better than in the "busy" case
All of the above is true unless the polling time is much greater
than the request service time (which is not the case for realistic
Your comments/feedback are always welcome.
Internet Systems Engineering
Silicon Graphics, Inc.