DNOTIFY support and some timing
Josef.Weidendorfer at gmx.de
Sun Feb 23 21:56:13 GMT 2003
On Sunday 23 February 2003 15:07, Christian Esken wrote:
> is there a good reason not to compile in DNOTIFY support by default?
> The code in kio/kio/kdirwatch.cpp already checks the kernel version.
> I agree, that there should be a possibility do --disable-dnotify ,
> but default should be enabled.
> For example SuSE8.1 (ships Kernel 2.4.19 and KDE3.0) has
> not compiled KDE with "--enable-dnotify".
Hmm. That's not our problem, though.
Doesn't SuSE use FAM with DNOTIFY? This way, KDE programs should never need to
do polling at all...
> AFAIK KDE3.0 already had dnotify support?!?
> Remark: I came across this, while working on a list of tips on how to
> use KDE3 on slow computers. On "low end" computers like mine
> (PIII - 450Mhz, 128MB Ram) doing polling has MAJOR impact on
> overall KDE performance. Application startup and overall resposiveness
> is much better with DNOTIFY. I blame this on the continuous task switching
> from and to kded.
You may be right. What's the sustained activity of kded in top?
OTOH, DNOTIFY has drawbacks, too: If you write a big file, for each "write"
syscall a DNOTIFY real-time signal is sent to each process watching the
Can you open konqueror in your HOME, and check the result of a
"while(true) do echo >> $HOME/log; done" in top?
I get a full loaded system with 73% system load, 50 % user CPU for fam, only
13% for bash, 4% konqueror and a busy thumbnail kioslave when preview is on.
This explains why DNOTIFY sucks badly. The problem is that there is no
Just now I have an idea to solve this:
* When getting a DNOTIFY/FAM signal, switch DNOTIFY/FAM off for this
directory/file and switch to STAT polling (only for this dir/file). This
should be quite fine even with NFS mounted dirs.
* STAT polling will happen every 0,5 seconds. Thus, delay/merging is done
automatically, and LINUX won't produce realtime signals like mad.
* If a STAT on the changed file doesn't show any change, switch back to
What do you think of this?
Perhaps we should trigger this mechanism only when detecting a flooding of
change signals (switching on/off a FAM watch on every change signal can be
> Examples (both time everything was compiled including --enable-debug=full
> Application With / without DNOTIFY support (Time used for launching App.)
> kwrite 4-6s / 6-10s
> kedit 2-3s / 3-5s
I don't understand how 0,5 seconds poll interval can make such a bad
behaviour. OK, kded watches around 40 directories. We should switch to
VFolders and get only a few dirs to watch for kded...
You can change the STAT polling interval in global KDE config
(.kde/share/config/kdeglobals) to e.g. 2 secs:
More information about the kde-core-devel