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

List:       kde-devel
Subject:    Re: FAM and 3.1rc3
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2002-11-30 2:11:01
[Download RAW message or body]

On Saturday 30 November 2002 01:29, Manuel Amador wrote:
> > Hi,
> >
> > the reasoning behind FAM is to keep CPU resources low for applications
> > that want reaction on file changes.
> > The need for this is *not* given when only one application is looking for
> > changes in a local directory: it can do polling at reasonable intervals.
> > This is the case with Konqui when you disable FAM and dnotify. As you
> > say, you get perfect and reasonable behaviour.
>
> Yes but FAM should also behave sanely, if it's enabled.  I really don't
> care about the option to disable it, 100% CPU usage with DD is a bug,
> and should be treated like that.

Are you caring for all FAM users in general or for yourself?
This is NOT a FAM bug (again see other mail). It's your distributions fault to 
patch the original FAM package to support dnotify. So general, this bug 
doesn't exist.

If your distribution forces you to use all eye-candy available in KDE by 
configuring this as default, even when installed on a 5 year old machine, is 
KDE the one to blame?

>...
> > * the directory to watch for changes is remotely mounted. As STATs over
> > NFS are slow,
>
> why?

Any network access can't be faster than a ping. And it influences network 
traffic, slowing down access times for all users on that network, plus puts 
load on the file server.
As said, the STAT usage needs regular polling (e.g. every few seconds). Thus, 
leading to a constant increase of net traffic. FAM on the contrary only sends 
something over the net when there is a file change.

> > Drawbacks of DNOTIFY:
> > - DNOTIFY forces FAM to open the directory which contains files to be
> > watched. This means problems with unmounting devices. Simple advice: Kill
> > the FAM daemon before unmounting ;-)
>
> OH!  That's the sucker!  This pinpoints to errors in the conceptual
> implementation.

Yes. DNOTIFY is conceptually not usable for watching files that can be 
unmounted ;-)

> > - DNOTIFY has *no* event delaying. For every write syscall to a watched
> > file, DNOTIFY produces immediatly a signal (for FAM).
>
> FAM should keep track of signals and throttle them.  I know this is a
> dnotify bug, but barring swift corrections to the kernel code, FAM
> should make do with what it has.

The user application has no possibility to limit/throttle realtime signals 
delivered to it once it has requested them. It simply has to avoid realtime 
signals at all if they could come in at a high rate.
Yes. This is a bug in the DNOTIFY support in FAM.
Aside from that, it doesn't need to notify for every signal it gets. A bug, 
too.

> > My advice:
> > - Use FAM, but recompile *without* dnotify support.
> > - Blame your distribution for using the problematic dnotify support for
> > FAM. - Mail the LINUX kernel list for adding a "delay" option for dnotify
> > (e.g. signal generation is delayed by 200 ms after the event happend,
> > merging events) and for dnotify not being in the way for unmounting (e.g.
> > by using a single /dev/dnotify for notifications or forcing closing of
> > dnotify file descriptors on unmounting).
>
> isn't it easier for FAM to detect multiple close events and merge them
> into one single application event to be sent?  There might be a reason
> why you want real time notification in apps using dnotify...

Yes. But the delivering of the signal itself is already unneeded load.

Josef

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]