[Top] [All Lists]

Re: Different select/poll implementations

To: state-threads@xxxxxxxxxxx
Subject: Re: Different select/poll implementations
From: genes@xxxxxxxxxxxxxxxxxxxxxx (Gene Shekhtman)
Date: Tue, 9 Jan 2001 16:43:35 -0800 (PST)
In-reply-to: Dan Melomedman <> "Different select/poll implementations" (Dec 23, 1:09pm)
References: <>
Sender: owner-state-threads@xxxxxxxxxxx
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.


Gene Shekhtman
Internet Systems Engineering
Silicon Graphics, Inc.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Different select/poll implementations, Gene Shekhtman <=