lkml.org 
[lkml]   [1999]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > 15,000 Simultaneous Connections
Mike Jagdis wrote:

> On Mon, 6 Sep 1999, Steve Underwood wrote:
>
> > So, the solution is to fix the clunky design of select, right? I'm not convinced
> > that dealing with a huge number of threads is any better than scanning a huge
> > select, anyway. Especially on a processor like the x86, which has scanning
> > instructions that can be used to scan the list quite quickly.
>
> You might be able to scan fdsets quickly at the user level but
> internally select has to scan the list and call the check routine
> for every interesting descriptor. I've been working on the kernel
> implementation of select/poll and can tell you that if a one
> descriptor select takes 40-50 *micro*seconds a 1000 descriptor
> select will be up in the region of 8-10 *milli*seconds (on my
> 6x86 P150+).[1]
>
> The current select/poll implementation can be improved significantly,
> especially in the blocking case, but the overhead will still increase
> with the number of descriptors because select/poll does not, and
> cannot, remember what descriptors are interesting. This would be
> easy to fix with a new API. Suggestions are welcome - particularly
> from people who might actually be interested in using it in earnest.

This is incorrect. Poll is a rather dumb design, as it fails to remember anything
useful, and forces extensive searches. On the other hand, select only requires that
you generate the appropriate offset into a bit array to check if an fd is of interest
- much faster. The problem is that select is now emulated through poll, aggregating
the total dumbness of the two! Neither poll nor select was well designed, but poll is
much dumber than select. poll takes far too much RAM, too. A 15K fd poll would
consume over 100K just for the list of fds. Sure, poll is concise for just few sparse
fds, but that's hardly ever what you want to select/poll.

The good things about poll are that it has separate arrays for the request and
response, and that it has finer granularity over what you can wait for. Most calls
require either the same request pattern as previous call, or a slightly modified
version, allowing for a few fds which have come and gone. I can't see much else that
makes sense in the design of poll.

The good things about select are efficient insertion and deletion of fds from the
list, and a compact request/response format for anything but the rare requirement to
wait on a few sparse fds. The bad things are a single pattern for the request and
response, requiring the wasteful regeneration or recopying of the request pattern;
inefficiency dealing with the bit list on machines that lack appropriate scanning
instructions; a very weakly defined notion of an "exception condition"; and some
pretty dumb macros for handling the bit list. Of course, any user can fix the last
problem themselves, and I assume they usually do.

I think the sane scheme would be a call like select, but with separate request and
response lists. It would probably drop the exception option, since it is nearly
useless anyway. It might (just might) add further selection lists akin to the other
options in poll.

I can't imagine why poll has replaced select in the kernel. Select looks bad by
objective measure, but looks pretty good compared to poll.

Steve



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.272 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site