Date: Thu, 28 Jan 1999 16:10:26 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: HighWind Software Information <info@highwind.com> Cc: current@FreeBSD.ORG Subject: Re: Locked at 100% User CPU Message-ID: <199901290010.QAA11960@apollo.backplane.com> References: <199901282130.QAA13214@highwind.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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?199901290010.QAA11960>