: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