#17 possible cpu hogging

[Rafal Wijata]

I verified that under FC6 and RHEL4u4 with gamin (and not fam) installed.
since fileschanged issues select() with only 5miliseconds timeout, it's possible that calling select 200 times per second may lead to unexpected high cpu usage.

Why the timeout is so small?
Why poll() is not used instead of select()?
Maybe the timeout should be configureable?

[Ben Asselstine]

Logged In: YES
user_id=564659
Originator: NO

Can you please verify if fileschanged is using too much CPU? You might try cutting and pasting from the `top' program.

Thanks,

Ben

[Rafal Wijata]

Logged In: YES
user_id=996150
Originator: YES

I have to apologize for reckless report.
1. fileschanged was spawned in recursive mode on directory with quite large number of files/dirs (~6000 currently)

2. I advised my staff to use fileschanged, and the feedback was that too much cpu was used, strace on fileschanged showed the select() potencial problem.

3. After investigation it turned out that the cpu hogging is in fact done by gam_server and not fileschanged.
Lot of stat64s. Strange, I thought that on FC6 with gamin and kernel with inotify support it should just wait for kernel notification instead of continous statin files. I'm going to ask for that the gamin team.

You may close this bug as invalid therefore.

But don't You think that 200 selects per second is too much?

[Nobody/Anonymous]

I ran the following commands:

% cd /tmp
% touch emptyfile
% fileschanged emptyfile

I checked with powertop(1):

Top causes for wakeups:
56.1% (1419.6) fileschanged : hrtimer_start_range_ns (hrtimer_wakeup)

I also checked with top(1). I have an Intel Core2 Duo T5450 at 1.66GHz,
and top shows fileschanged using 3% CPU with the above test.

Using 3% CPU at all times seems excessive to me, but I am more concerned
about the wakeups. Is it necessary to have a timeout, especially one so
low? That defeats the biggest reason to use inotify or similar.

Thanks for fileschanged! I hope that this issue can be addressed.