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" <[EMAIL PROTECTED]>
To: "Dan Kegel" <[EMAIL PROTECTED]>
Cc: "Vincent Sweeney" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Kevin L.
Mitchell" <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
