:In libc_r, I don't think the code in uthread_kern.c's
:_thread_kern_select() scales at all.
:
:As the number of network connections (TCP) to my application grows, I
:believe this routine takes longer and longer and my CPU goes to 100%
:user space.
:
:Something makes me believe that this routine has an n^2 (or worse)
:problem. Seems to relate to the number of fd's to select() on. At
:about 300-400, even a P2 400Mhz gets max'd out and gets nothing done.
:
:Anybody have a feeling as to what is wrong here?
:
:-Rob

    This code looks pretty bad, all right.  It looks like it is O(N^2)
    in PS_SELECT_WAIT(), especially if descriptors get randomly strewn
    amoungst the threads.  It also looks like it is regenerating the FDS masks
    on each call completely from scratch.  It also looks like it is
    scanning the entire thread list - both waiting and running threads,
    to prioritize the next thread to run and then scanning it again
    to select the thread priority, then scanning the whole list yet
    again to find the one it wants to run.

    This is massively unscaleable code.  Is anyone actively working on
    it?

                                        -Matt
                                        Matthew Dillon 
                                        <dil...@backplane.com>

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to