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