bug#33194: 26.1; Auto-revert mode causes emacs to use 100% cpu whenever a file is being written to in the home directory

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

>> It was outside of emacs.  SCP would trigger the cpu usage in emacs,
>> rsync would not (oddly).  Both "cat
>> /dev/zero > somefile" and "dd if=/dev/zero of=somefile" would
>> trigger it if somefile was in my $HOME
>> directory, but none of these would trigger it if I did it in, for
>> example, $HOME/Downloads/
>
> Isn't this expected?  Auto-revert watches the directory of the file,
> so if a lot of changes happen in that directory, Emacs will get a lot
> of file-change notifications, and will need to process them.

Yes.

> If you don't like this, customize auto-revert-use-notify to not use
> notifications.  Or maybe there's some system-wide customization of
> inotify that determine the max frequency of inotify notifications when
> the changes are to the same file.  (I don't know enough about inotify
> to say anything more specific, sorry.)

From inotify(7):

       If successive output  inotify  events  produced  on  the  inotify  file
       descriptor  are  identical (same wd, mask, cookie, and name), then they
       are coalesced into a single event if the older event has not  yet  been
       read (but see BUGS).  This reduces the amount of kernel memory required
       for the event queue, but also means that an application can't use  ino‐
       tify to reliably count file events.

Maybe we will get the burst of events due to scp; a simple cp might
profit from the described behaviour.

One defense action which comes to mind is to manage the incoming
events. If there is a burst of `change' events in a short time, they
could be cumulated to one event, as inotify does. Implemented in
`file-notify-handle-event', this would applicable to all file
notification backends, and not only to inotify.

Best regards, Michael.