On Thu, Jan 28, 1999 at 04:10:26PM -0800, Matthew Dillon wrote: > :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?
The uthread code does not scale well, nor perform particularly well. I have demonstration code that suggests a 1-1 kernel threads implemention can create threads 5-20 times faster than the uthread code. It can do context switches (even without any fds open) from 2-3 times faster (just a few threads) to 15-20 times faster (~100 threads) to 200+ times faster (~1000 threads). Don't know if anyone is working on uthreads. IMO rather than trying to fix the uthread code, which would be a significant project, it would be better to convert it to a N:M kernel thread implementation. It wouldn't be all that much more work than getting the user thread code in first rate shape. But, either way I think its a fairly big project. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
