lkml.org 
[lkml]   [1998]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread implementations...
Alex Belits writes:
> On Fri, 19 Jun 1998, Richard Gooch wrote:
>
> > David S. Miller writes:
> > > Date: Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
> > > From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
> > [...]
> > > Unix multiplexing facilities -- select and poll -- are wake-all
> > > primitives. When something happens, everything waiting is awakened
> > > and immediately starts fighting for something to do. What a waste.
> > > They make a lot of sense for processes though. On NT completion
> > > ports provide wake-one semantics... which are perfect for threads.
> > >
> > > Yes, this does in fact suck. However, the path to go down is not to
> > > expect the way select/poll work to change, rather look at other
> > > existing facilities or invent new ones which solve this problem.
> > > Too much user code exists which depends upon the wake-all semantics,
> > > so the only person to blame is whoever designed the behaviors of these
> > > unix operations to begin with ;-)
> >
> > On the other hand you could say that the UNIX semantics are fine and
> > are quite scalable, provided you use them sensibly. Some of these
> > "problems" are due to applications not being properly thought out in
> > the first place.
>
> #ifdef SARCASM
>
> "Thundering Herd Problem II", with all original cast... ;-) This time it's
> not accept(), but poll(), and the whole thing is multithreaded...
>
> #endif

Maybe it's because it's late, but I'm missing what you're getting at
here...

> > If for example you have N threads each polling a
> > chunk of FDs, things can run well, provided you don't have *each*
> > thread polling *all* FDs. Of course, you want to use poll(2) rather
> > than select(2), but other than that the point stands.
>
> Can anyone provide a clear explanation, what is the benefit of doing
> that in multiple threads vs. having one thread polling everything, if the
> response on fd status change takes negligible time for the thread/process
> that is polling them (other processes complete the operation while polling
> comtinues)? I have a server that uses separate process mostly for polling,
> however I'm not sure what poll()/select() scalability problems it may
> encounter if used with huge fd number.

Both poll() and select() have scalability problems: it takes of the
order of 2-3 microseconds (Pentium 100) per FD to scan the list of
FDs. With thousands of FDs, mostly inactive, this time can start to
dominate (especially now that the TCP stack rocks). This is wasted
kernel time.

So you can solve this by dividing up your FDs amongst a group of
threads. Thus each thread only has to scan a short list. Of course,
the total number of FDs that has to be scanned is the same, so you may
ask where is the saving? The answer is that, assuming most FDs are
inactive (quite a reasonable assumption as it turns out, when looking
at timescales of a few ticks), chances are that not all your threads
will have to be woken up. And the less threads that have to be woken
up, the less FDs need to be scanned over any (short) period of
time. And there is your saving.

select() doesn't work so well in this scheme, because a thread that is
scanning FDs 9000-10000 still has to do that bit-testing for FDs
0-9000. Hence you are better off with poll(), even though the per-FD
cost of poll is higher. The poll2() syscall I implemented is the way
around this and other problems, but I've left that dormant since
2.1.5x (I'll get back to it for 2.3.x) because there is more work to
be done on the implementation of select() and poll() before the
benefits of poll2() really show. That work I've also left dormant till
2.3.x, since it wasn't adopted around 2.1.5x and I don't have time to
push it just yet. Have a peek at:

ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.1/fastpoll-readme

if you're interested.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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