Messages in this thread | | | From | "Vincent Sweeney" <> | Subject | Re: PROBLEM: high system usage / poor SMP network performance | Date | Tue, 12 Feb 2002 18:48:00 -0000 |
| |
Well I've recoded the poll() section in the ircu code base as follows:
Instead of the default :
... nfds = poll(poll_fds, pfd_count, timeout); ...
we now have
... nfds = poll(poll_fds, pfd_count, 0); if (nfds == 0) { usleep(1000000 / 10); /* sleep 1/10 second */ nfds = poll(poll_fds, pfd_count, timeout); } ...
And as 'top' results now show, instead of maxing out a dual P3-800 we now only use a fraction of that without any noticable side effects.
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14684 ircd 15 0 81820 79M 800 S 22.5 21.2 215:39 ircd 14691 ircd 12 0 80716 78M 800 S 21.1 20.9 212:22 ircd
Vince.
----- Original Message ----- From: "Andrew Morton" <akpm@zip.com.au> To: "Dan Kegel" <dank@kegel.com> Cc: "Vincent Sweeney" <v.sweeney@barrysworld.com>; <linux-kernel@vger.kernel.org>; <coder-com@undernet.org>; "Kevin L. Mitchell" <klmitch@mit.edu> Sent: Sunday, February 03, 2002 8:36 AM Subject: Re: PROBLEM: high system usage / poor SMP network performance
> Dan Kegel wrote: > > > > Before I did any work, I'd measure CPU > > usage under a simulated load of 2000 clients, just to verify that > > poll() was indeed a bottleneck (ok, can't imagine it not being a > > bottleneck, but it's nice to have a baseline to compare the improved > > version against). > > I half-did this earlier in the week. It seems that Vincent's > machine is calling poll() maybe 100 times/second. Each call > is taking maybe 10 milliseconds, and is returning approximately > one measly little packet. > > select and poll suck for thousands of fds. Always did, always > will. Applications need to work around this. > > And the workaround is rather simple: > > .... > + usleep(100000); > poll(...); > > This will add up to 0.1 seconds latency, but it means that > the poll will gather activity on ten times as many fds, > and that it will be called ten times less often, and that > CPU load will fall by a factor of ten. > > This seems an appropriate hack for an IRC server. I guess it > could be souped up a bit: > > usleep(nr_fds * 50); > > - > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |