[collectd] I guess we need a config file

[Florian Forster]

Hello,

On Wed, Dec 14, 2005 at 01:35:16PM +0100, Niki Waibel wrote:
> gathering information of a system is never a matter of cpu speed. it
> is more about how fast the kernel or disk reacts to the requests. i
> think there is simply no need to spread the threads on cpus.

right, CPU performance is not an issue. The time the kernel or daemon or
whoever needs to get a lock on some counter is more likely to be a
bottleneck, but I'm positive that's not a problem at all.

The second slowest operation collectd does is opening files. The
operating system is quite good at opening files, so that's not the
problem either.

So one and only problem so far is sockets. So far the modules using
sockets are `ping' and `hddtemp'. `hddtemp' connects to localhost which
should be reasonably fast. `ping' on the other hand waits for the other
host to answer. If we assume an average roundtrip time of 20ms collectd
simply sits there and waits for 172.8 seconds every day. This value
(linearly) grows with the number of hosts you ping. This is my
motivation to look into threads.

> the advantage (in regard to collectd, imho) of the gnu pth is
> that they are non-preemptive. another thread runs only
>         a) if the program requests it
>         b) if the running thread starts waiting for sthg
> this has the advantage that the modules need not take care of any
> concurrency. basically you can just leave them as they are!!! no
> locking of curtime or any global var is necessary.

Are you sure this will result in a speedup? If I have only one
kernel-thread, doesn't that mean that the entire programm has to wait
for a syscall sooner or later?

Although I am thinking about preemptive, parallel threads I don't think
the plugins need much attention: What I want is one thread for each
plugin, so the functions within a plugin are not called in parallel.
Places where locks may be neccessary would be
- plugin_submit
- rrd_update_file
- plugin_* (the routines that read/change the linked list)
- cf_*     (the routines that read/change the linked list)

We can ignore the `plugin_*' and `cf_*' functions if we do
initialization sequencially..

> also some system functions are not preemptive thread save,
> but most of them are non-preemptive thread save.

This is true for system functions that allocate memory, e.g. `stat' (or
`lstat'). So I think most functions that are used often should be okay..

So, my points are:
- Locking issues are not that difficult to handle
- Advantages, as I see them so far, don't justify the integration of
  another library

Of course, as long as I haven't started developing in one direction or
another I'm still easy to convince I'm wrong ;)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20051214/96897d80/attachment.pgp