timed eating resources ?

[Uwe Dippel]

This is just for curiosity:
I'm running 3.3 and 3.4 on the same machine, same configs, etc.
With 3.4, the highest consumer of CPU is timed; with 3.3 this is not the
case.
On 3.4 it consumes more CPU-time than ppp / pppoe together and more than
zope:

3308 root 2 0 436K 304K idle poll 22:40 0.00% timed
23971 zope 2 0 18M 21M sleep poll 15:02 0.00% python2.1
27744 root 2 0 652K 1028K sleep select 11:03 0.00% ppp

As I said, curiosity ...

[Daniel Hartmeier]

On Sun, 16 Nov 2003 11:21:50 +0800, Uwe Dippel wrote:

> With 3.4, the highest consumer of CPU is timed; with 3.3 this is not the
> case.

> 3308 root 2 0 436K 304K idle poll 22:40 0.00% timed

> As I said, curiosity ...

Oops, lost time precision in the select() -> poll() conversion, which
basically causes a busy loop.

Daniel

Index: readmsg.c
===================================================================
RCS file: /cvs/src/usr.sbin/timed/timed/readmsg.c,v
retrieving revision 1.14
diff -u -r1.14 readmsg.c
--- readmsg.c 19 Aug 2003 19:41:21 -0000 1.14
+++ readmsg.c 16 Nov 2003 11:02:25 -0000
@@ -192,7 +192,8 @@

pfd[0].fd = sock;
pfd[0].events = POLLIN;
- if (!poll(pfd, 1, rwait.tv_sec * 1000)) {
+ if (!poll(pfd, 1, rwait.tv_sec * 1000 +
+ rwait.tv_usec / 1000)) {
if (rwait.tv_sec == 0 && rwait.tv_usec == 0)
return(0);
continue;

[Uwe Dippel]

On Sun, 16 Nov 2003 11:04:21 +0000, Daniel Hartmeier wrote:

> Oops, lost time precision in the select() -> poll() conversion, which
> basically causes a busy loop.

Thanks, is a good one. Applied, restarted timed and everything is back to
normal. Just FYI

Uwe