[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DNOTIFY support and some timing
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2003-02-23 21:56:13
[Download RAW message or body]

On Sunday 23 February 2003 15:07, Christian Esken wrote:
> Hello,
>
> 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.

I agree. 

>
> 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 
directory.

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 
notification delay/merging.

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 
DNOTIFY/FAM.

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 
heavy).


> Examples (both time everything was compiled including --enable-debug=full
> switch):
>
> 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:
[DirWatch]
PollInterval=2000

Josef

>
>
> Chris

[prev in list] [next in list] [prev in thread] [next in thread]