Date: Fri, 29 Jan 1999 09:22:02 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: HighWind Software Information <info@highwind.com>, current@FreeBSD.ORG Subject: Re: Locked at 100% User CPU Message-ID: <19990129092202.T421@tar.com> In-Reply-To: <199901290010.QAA11960@apollo.backplane.com>; from Matthew Dillon on Thu, Jan 28, 1999 at 04:10:26PM -0800 References: <199901282130.QAA13214@highwind.com> <199901290010.QAA11960@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990129092202.T421>