Thanks Cameron, Sorry to get back you late on this. yes, so if it is just purely just getting the message, and then discard, and then getting it again....there are a few optimization possible (sorry, i did not look at source, but just guessing): a. allocate a ring buffer, so as to be reused all the time, without allocation. b. if the config file (syslogd.conf) say discard, then then there should be ZERO copying of the messages generated by the printk() codes originating from kernel source codes. I instrumented the kernel source to do printk()....but because the execution path is hot, as it is traversed many times over, CPU activities really rises up very high.....but in actual fact my /var/log/messages is ZERO content. i am quite sure there is some under-optimization somewhere. Thanks. On Fri, Jan 23, 2009 at 6:30 PM, Cameron Simpson <cs@xxxxxxxxxx> wrote: > On 23Jan2009 17:34, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > | I did a simple thing - modified my syslog.conf: > | > | cat /etc/syslog.conf > | mail.none;authpriv.none;cron.none /var/log/messages > | > | So virtually, there is nothing to go to /var/log/messages, although my > | dmesg's output did output a lot of other stuff....as I instrumented > | the kernel to do printk()....something like every file traversal will > | generate several entries in dmesg output. > | > | Nevertheless, since /var/log/messages to get, as I check, its content > | is always zero (after I did an initial truncation) - why is syslogd > | showing such a high performance: > [...] > | Over a period of time, I observed that klogd and syslogd is toggling > | to be among the top few candidate all the time - toggling, meaning > | switching between one and another. > | > | Can someone explained this behavior? Shouldn't the syslogd be > | consuming almost zero cpu % since there is zero output to > | /var/log/messages? > > Not really. Your kernel logging is still _all_ going through syslogd, > which is quietly deciding not to _copy_ it into the messages file. But > it still has to consider and then discard) every kernel message. > > Cheers, > -- > Cameron Simpson <cs@xxxxxxxxxx> DoD#743 > http://www.cskk.ezoshosting.com/cs/ > > Anagram: Information superhighway <==> I'm on a huge wispy rhino fart. > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines > -- Regards, Peter Teoh -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
