On Friday 29 November 2002 18:21, Manuel Amador wrote: > El jue, 28-11-2002 a las 03:46, Michael Kreitzer escribi=C3=B3: > > I've noticed with FAM enabled in kde 3.1rc3 none of the io slaves see= m to > > realize when fam is inappropriate... I got stuck with an unresponsive > > system until I figured out FAM was using 100% cpu while KDE tried to = use > > it over 3 sftp connections and 2 smb connections.... this should not > > happen. My question is... is this a KDE bug or a FAM bug or a FAM > > misconfiguration on my part? > > Oh, and FAM causes millions of updates on a local open directory with > Konqueror, just when I retag an MP3/Ogg file with EasyTAG. After it's > finished tagging, Konqueror keeps flickering like mad for 10 seconds an= d > I can't use any other Konqueror windows. Disabling service sgi-fam in > xinetd does the trick, and Konqueror updates directories again, at a > sane speed. But isn't fam supposed to help performance by reducing > reads to find out whether an element has changed? Hi, the reasoning behind FAM is to keep CPU resources low for applications th= at=20 want reaction on file changes. The need for this is *not* given when only one application is looking for= =20 changes in a local directory: it can do polling at reasonable intervals. = This=20 is the case with Konqui when you disable FAM and dnotify. As you say, you= get=20 perfect and reasonable behaviour. The reason for FAM is given when * there is a large number of applications looking for changes in the same= =20 directory. FAM can centralize the actions needed, but notify each applica= tion=20 on a change. This *would* be needed if KDE applications keep an eye on their config fi= les:=20 Each KDE app would need to listen for changes to the file with global KDE= =20 configuration, too. Here, the centralized approach of FAM is helpful. You can specify FAM to only do STAT polling instead of using kernel suppo= rt=20 (e.g. DNOTIFY). * the directory to watch for changes is remotely mounted. As STATs over N= FS=20 are slow, you create unneeded network loading. When the FAM daemon is run= ning=20 on the server machine, the local FAM on the file server looks for *local*= =20 changes (perhaps again using only STAT polling, but that's fast when loca= l).=20 When a change is detected, the server FAM notifies all watching client FA= Ms=20 and these demultiplex the notification for each application on their mach= ine=20 which are interested in changes. The centralized approach of FAM is needed here, too: Suppose 1000 clients= =20 doing STAT polling over NFS instead of using FAM... How does FAM know about changes on *local* files? There is either - regular polling with STAT - using some kernel support: imon (IRIX), dnotify (LINUX), kqueue (BSD?) STAT polling every 0,5 seconds is mostly enough (configured when compilin= g=20 FAM). Disadvantage is a maximal delay of 0,5 s for events to be delivered= =2E STAT does *not* open the watched files are make a watched dir its cwd, so= =20 there will *never* be any problems with "device busy". Umounting devices = is=20 no problem with STAT polling. If there are huge numbers of files to be watched, or you want immediatly=20 notified about changes, use kernel support: * imon uses the /dev/imon pseudo device to get notifications from the ker= nel.=20 There's also a implementation for LINUX, but because of bad shape of this= =20 code, it's not in any legacy kernel and AFAIK no distribution has it buil= d=20 in. BTW, this is the IRIX way on SGI machines. * Don't know about kqueue (is this the right name for this service on BSD= ?) * dnotify on LINUX: This is in the legacy kernel. And that's the reason a= ll=20 distributions seem to have FAM built to use it (SUSE, Red Hat, Mandrake..= =2E). Drawbacks of DNOTIFY: - DNOTIFY forces FAM to open the directory which contains files to be wat= ched. This means problems with unmounting devices. Simple advice: Kill the FAM=20 daemon before unmounting ;-) - DNOTIFY has *no* event delaying. For every write syscall to a watched f= ile,=20 DNOTIFY produces immediatly a signal (for FAM). Worse, all DNOTIFY=20 applications (FAM, KDirWatch with dnotify support) use realtime signals.=20 These aren't merged by the kernel but queued and could lead to overrunnin= g=20 this queue (thus, the additional need for SIGIO handler). But this is nee= ded=20 as an attribute for the signal is the changed directory file descriptor, = and=20 thus the application knows the directory where the change happened. When=20 using a normal signal for dnotify, events could be missed: You would chec= k=20 *all* directories to be watched with STAT for actual change. That's not=20 really better than STAT polling alone. So if your MP3 tagging does 1000 1-char-writes, all watching applications= (FAM=20 or KDirWatch itself) will get 1000 signals delivered. This can make the w= hole=20 system unusable for a few seconds :-( Note: You can disable FAM and switch on DNOTIFY support in KDirWatch when= =20 compiling kdelibs. This has the same disadvantages as using FAM with dnot= ify. My advice: - Use FAM, but recompile *without* dnotify support. - Blame your distribution for using the problematic dnotify support for F= AM. - Mail the LINUX kernel list for adding a "delay" option for dnotify (e.g= =2E=20 signal generation is delayed by 200 ms after the event happend, merging=20 events) and for dnotify not being in the way for unmounting (e.g. by usin= g a=20 single /dev/dnotify for notifications or forcing closing of dnotify file=20 descriptors on unmounting). And don't blame FAM for the buggy behaviour of dnotify you noted. This is a fine system tool. Josef PS: Waldo, what do you think of requesting SIGIO signals for dnotify in KDirW= atch? You get signal merging, but have to STAT each watched entry (as already n= eeded=20 with SIGIO when the realtime-signal-queue runs over). At least this wouldn't keep konqui busy seconds after a huge number of si= gnals=20 from dnotify. But perhaps event merging/delaying in KDirWatch will be fine. (go down fr= om a=20 10 second lasting flickering in konqui with 100% load to only 1 second 10= 0%=20 load without flickering). The unmounting problem will still be there. When unmounting from KDE, the= re=20 could be a DCOP broadcast to stop watching in all KDE applications. But t= his=20 does not work with umount from the shell or supermount. Perhaps I should try to hack dnotify myself, sent the patch to the kernel= list=20 and hope somebody correctifies that bad hack of myself to perhaps allow i= t=20 for application to the legacy LINUX kernel. Or try to cleanup the imon patch for LINUX. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<