[RFC] [PATCH] syslogd polling

=== syslog vs powertop ===

If I run powertop[1], syslogd's polling shows up (at a very low
level). I've already patched the most frequent pollers on my idle
system, so I started looking at the more simple of the minor offenders
- which I'm more likely to be able to understand than the complex GUI
offenders.

I found that syslogd shows up because it has a constant 30s poll cycle
  to log --MARK-- at longer intervals (minimum 1 minute) and to flush
duplicate messages ("last message repeated 2 times"). Ideally it
should be able to poll less frequently when there are no pending
duplicate messages. As I said, syslogd is a very minor offender; I
can get my (idle) system down to 5 wakeups/second and syslogd is
responsible for less than 0.1 of those, so it's difficult to argue
that this is anything more than a cosmetic issue. On the other hand,
syslogd runs on virtually all linux PCs - maybe it would make a
difference overall.

I also noticed that due to some unusual indentation in domark(),
disabling --MARK-- with "-m0" has an undocumented feature. It appears
to stop pending duplicate messages from being flushed by the 30s
timeout, so that they will only get flushed when a new message is written.

=== my patch, using posix timers to help cope with non-monotonic
system time ===

I've written a patch to reimplement the polling to prevent unnecessary
wakeups. Since the above "feature" was undocumented I didn't preserve
it, but I can change that back if it's really supposed to work that
way. Attached. I've tested that it stops syslogd showing up in
powertop, and that both --MARK-- and duplicate messages work as
before. It adds a couple of lines of debugging which should help
figure out any problems, and demonstrate how it works.

The main issue with my patch is that it uses POSIX timers, which
limits portability / backwards compatibility. I haven't sprinkled it
with ifdefs - it would need a bit more abstraction before you could
think about doing that.

I was worried that if I did it using alarm() and time() like the
existing code, it might not behave as well if the time went
non-monotonic (specifically, backwards). With the regular 30s alarm()
in the existing code, its possible to handle two separate
coarse-grained timers by counting the alarms. Once you start sleeping
different amounts of time depending on what you need to do, you have
to rely on time() more to work out which tasks to run now and how long
to sleep next.

I know that tweaking the system is generally going to be a
Questionable Idea, MARK and duplicate messages aren't critical
features, duplicate messages will always get flushed when a new
message is written anyway, and I still left some uses of time() in
there. I'm probably too scared of regressions.

So, would you like my patch with posix timers and possibly #ifdefs to
keep it running on older systems, or only using time() and alarm() but
  risking strange behaviour if you change the system time - or is
there anything else that means it wouldn't be accepted?

Thanks,
Alan

[1] http://www.linuxpowertop.org