Re: > 15,000 Simultaneous Connections

Chuck Lever (cel@monkey.org)
Mon, 6 Sep 1999 13:29:55 -0400 (EDT)

On Mon, 6 Sep 1999, Mike Jagdis wrote:
> On 6 Sep 1999, Andreas Schwab wrote:
>
> > Mike Jagdis <mike@roan.co.uk> writes:
> >
> > |> The main cost of select and poll, on the kernel side, is scanning
> > |> the fds to see what is ready. The way select and poll are usually
> > |> used we want a means to express an interest in an fd and then
> > |> receive a stream of "events" as fds change state.
> >
> > That's what SIGIO is for.
>
> Partly. But you want to ask for a real time signal to be used
> so that you get the fd as well. Then there's a limit on the
> number of signals that can be queued at once and, I think, if
> you hit the limit signals get dropped (or turned into non-queuing
> SIGINFO) which can be a problem. Plus sharing the signal queue
> between tasks/{processes,threads} isn't possible. And if you
> are delivering to a process group each process gets its own
> siginfo allocated and queued. Then there's all the signal
> code adding to the overhead on each event. Yup, signals are
> an option, but they have their own set of gotchas and scalability
> issues which are probably even less well understood than
> select and poll :-).

i have to agree with all of this -- using queued signals is not a win in
terms of application complexity. add to this that the C library will want
to use signals for its own purposes, and there is no standard way for an
application to discover what signals are already in use.

gaurav banga and jeff mogul presented a paper at the june usenix technical
conference which describes a new kernel API for scalably managing I/O
events. the link:

http://www.cs.rice.edu/~gaurav/papers/usenix99.ps

niels provos here at the scalability project has designed a new version of
poll() that provides callbacks to device drivers so that poll() doesn't
have to scan a list, it simply waits for the callbacks. he has ported
this to a late 2.3 kernel, and is testing it. is anyone interested in
helping to test? is this something we want to get into the kernel?

- Chuck Lever

--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>


The Linux Scalability project:
	http://www.citi.umich.edu/projects/linux-scalability/




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/