From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#33194: 26.1; Auto-revert mode causes emacs to use 100% cpu whenever a file is being written to in the home directory Date: Tue, 30 Oct 2018 09:39:50 +0100 Message-ID: <874ld3bzft.fsf@gmx.de> References: <878t2gbisr.fsf@gmx.de> <83pnvskl8b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540888692 9688 195.159.176.226 (30 Oct 2018 08:38:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 08:38:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Justin Van Winkle , 33194@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 30 09:38:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPXL-0002Qz-SW for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 09:38:08 +0100 Original-Received: from localhost ([::1]:51596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHPZS-0000N4-5W for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 04:40:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHPZI-0000LQ-Fa for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 04:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHPZC-0002hV-Nf for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 04:40:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHPZC-0002hB-IE for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 04:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHPZC-0002Oi-AM for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 04:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Oct 2018 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33194 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33194-submit@debbugs.gnu.org id=B33194.15408888009205 (code B ref 33194); Tue, 30 Oct 2018 08:40:02 +0000 Original-Received: (at 33194) by debbugs.gnu.org; 30 Oct 2018 08:40:00 +0000 Original-Received: from localhost ([127.0.0.1]:53248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPZA-0002OP-D4 for submit@debbugs.gnu.org; Tue, 30 Oct 2018 04:40:00 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:38495) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPZ8-0002OB-B6 for 33194@debbugs.gnu.org; Tue, 30 Oct 2018 04:39:58 -0400 Original-Received: from detlef.gmx.de ([213.220.159.224]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYcJi-1g4qlJ1JLO-00VQbi; Tue, 30 Oct 2018 09:39:51 +0100 Original-Received: from detlef.gmx.de ([213.220.159.224]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYcJi-1g4qlJ1JLO-00VQbi; Tue, 30 Oct 2018 09:39:51 +0100 In-Reply-To: <83pnvskl8b.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Oct 2018 08:21:56 +0200") X-Provags-ID: V03:K1:R7QscXJtBSTSYlH8Dyk6MBR3eyrCzD+rCk3gpWuYi5VbIB1qkCO G0G574wO5E6vvSnbtlPDC2j7Reng22XxuoJb3zGxAm2binsOX8HHyrjoHTaqEsYM+PwQmtk Pmp24SCxYKZXleKoi9/x5ku4A932xX+0QZfw6G5lcU5gW7uTEit9suBlIFu22sWU/GhTYKK JPRTvAm7D/WUn93RjZQUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:wxCFdukjMVw=:MRfPjrfIqB3eubgZF0kVFT s5Tv4Rt70TV5tQ4OIRqhJe1xG8B8BectfALECt38fV+WbR69Ek43nuZJhv6Y4KwpaPGYCgm+8 bNnUiyPT8YTrcqoFhybigo6d6Aim8jdGkyyF3urfaqBy0U1GGZJkwec82F/tOLvBi9fqAP4RH MGsuFLckXekA8+0HcZHD/uwZZp/QG5Lr9KycUv4f1RIUSkhWyAd/EmoDcqcBoglcJp9ASis9x uBK9yw55+Y8HsmoCshk5N0jFJD0PlselNgDO9FJxE96KwRKFy8czoyhxRp1NcjRBDg2c9QEuk Y70MoILtKjy7vMFTiv8wPLbBhbXYV6EeP9viQhETbVhGphFYV/t2uNEmo9hYlkaCrHTM49Mpb vAEVhtcagEghYe24FewS40bVcREhRvbAzWgJuzkAPFzBY5SnnGtg7OqDhtee6oJ2SH9H327HI 3KMSaweem2pPmzFDLy+dUNKIF+ysiKLXIqgBBlisJLWa1+LmmcXXnZOTNrxHA8tgdXqRmcAvE nIX/JDobEFX8UIxx5lb+ew2G0Sfy4bY+rTLF9o8zvw+ARy/41sr8Aq9nRGKFIBsm97kkblUPZ tXIlLVjZqNpkRDU3ZttenBvEbDNH1WDA79qZSrAxT78LXWlFYdlzSY2H9L492fn11UnmN+MEE NaHPdJy7vzknXYKh3AUSXfaV+5bPFkwMeAyh3n2cl3F5akCqv6dNaI/9gy4Kr5a0uOgR4R+BR 2qdhedDeXBlrSqw5taojHZWGnvisYbQGwpA7/3Ak55/JomGCL5YG72RviO4sgQdbXHrnGXPt X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151815 Archived-At: Eli Zaretskii 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=3D/dev/zero of=3Dsomefile" 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 f= ile descriptor are identical (same wd, mask, cookie, and name), then t= hey are coalesced into a single event if the older event has not yet b= een read (but see BUGS). This reduces the amount of kernel memory requi= red for the event queue, but also means that an application can't use i= no=E2=80=90 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.