Max Kellermann wrote: > Waking up daemons without a reason is sloppy design most of the time. > A quick look at the conntrackd code made me believe that conntrackd > just doesn't check when the next scheduled event is due, and instead > performs a check on all alarm objects in the current step 5 times a > second. That is easily fixable, and not only saves CPU cycles and > power, but also leads to better overall design. Indeed. This makes a lot sense to me. I have committed a patch to SVN to wake up the daemon only if there is any alarm event to process instead of polling. I'll do some testing of it tomorrow. > The whole alarm.c looks like duplicated effort, you could have used > libevent instead. Well, I think that libevent is too much since conntrackd handles not that many descriptors and the alarm implementation is enough for what conntrackd needs IMO. > By the way, I saw an add_alarm() in cache_timer.c, but its callback > function "timeout()" neither sets a new "expires" value, nor does it > delete the alarm object. That may lead to integer underflow in the > next do_alarm_run() invocation. I have also changed this since I needed it for the lastest commit. However, AFAICS such underflow doesn't ever happen in 0.9.5. >> I'll investigate this. Are you using 0.9.5 or a SVN snapshot? Are >> you using the `alarm' mode (formely known as `persistent')? > > I am using the most recent release, i.e. 0.9.5. I have no idea about > "alarm" or "persistent" mode, and I did not find any documentation on > this. I am using the "stats" example configuration from the tarball. Please, could you check out a working copy from SVN and tell me if the problem that you're reporting persists? -- "Los honestos son inadaptados sociales" -- Les Luthiers - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
