From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
To: Eli Zaretskii <eliz@gnu.org>
Cc: chiaki.ishikawa@ubin.jp, larsi@gnus.org, 39413@debbugs.gnu.org,
npostavs@gmail.com
Subject: bug#39413: 26.2; Emacs gets hung
Date: Mon, 16 Aug 2021 08:27:01 +0900 [thread overview]
Message-ID: <e384638a-8340-b615-778a-877ba8708e85@yk.rim.or.jp> (raw)
In-Reply-To: <838s17dtpa.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]
On 2021/08/12 16:10, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, npostavs@gmail.com, 39413@debbugs.gnu.org,
>> chiaki.ishikawa@ubin.jp
>> From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
>> Date: Wed, 11 Aug 2021 22:41:56 +0900
>>
>> What about the dump below, which was in the *Messages* buffer following
>> dump I sent.
>> I am afraid I picked up the wrong dump in my previous e-mail.
>>
>> Now, is "gc-elapsed" the elapsed time spent in the GC routine?
>> If so, the two samples at the end of the dump here certainly look
>> suspicious.
> Yes, they show a couple of GCs that took about 150 to 200 sec. That
> is indeed excessive, but gc-elapsed reports the wall-clock time, not
> the CPU time, so if Emacs wasn't getting processing resources to run,
> which could happen on a stressed system, that could explain the long
> GC times. Note that other GC cycles, both before and after the 2
> problematic ones, took much less time. And the statistics returned by
> memory-use-counts doesn't show any excessive number of Lisp objects;
> in fact, my current Emacs session, which runs for 9.5 days, has an
> order of magnitude more objects than what you show, and yet GC cycles
> here are barely perceptible.
>
Hi,
Thank you for your reply.
So gc-elapsed is the elapsed wall-clock time.
Is there a function to obtain CPU time in Emacs Lisp?
On BSD, many years ago, I wrote a short routine that uses
resource-related system call. I am using Emacs under linux now, and I
assume similar calls exist under linux. I checked the manual.
I will use getrusage(2), which seems to be BSD-compatible, to obtain the
resource usage statistics and include the numbers in my post-gc-hook result.
OTOH, I have always assumed that Emacs DID eats up CPU while longish GC.
You may recall the graphics that showed the usage of a CPU core going
all the way to 1000 in my previous e-mail (xosview). I am attaching it
again.
I used the graphics to show the memory usage (hand-drawn red circle) in
my previous e-mai.
But if you look slightly above, you will notice CPU core #4 is used 100%
(!).
That is emacs process. No other process is running that earnestly at
that moment.
Thanks to many cores (actually I allocate 7 cores), the linux desktop
was responding swiftly and xosview was recording system resource usage
as the graphics shows. Only Emacs process could not respond to window
repaint request from X when I re-arranged the windows layout, and that
is why the Emacs window is garbled (hand-drawn blue circle was placed at
the upper-left of the un-repainted area that remained black).
I believe Emacs indeed was eating up the CPU time in a busy loop or
deeply nested calls. (maybe a loop that could be handled in a for loop
with a relatively shallow stack was handled by a recursive call that can
be nested as deep as the list length?)
Numbers from getrusage() will give us additional insight on this matter
hopefully.
Thank you again for all your tips.
Chiaki
PS: I found profiler-cpu-* functions, but I don't think it is wise to
run them during GC since they seem to allocate vector tables. However,
taking a snapshot of strack trace every now and then during GC seems
attractive for my investigation to figure out WHERE in GC, the excessive
time is spent.
[-- Attachment #2: emacs-hung-2.PNG --]
[-- Type: image/png, Size: 283491 bytes --]
next prev parent reply other threads:[~2021-08-15 23:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 9:32 bug#39413: 26.2; Emacs gets hung chiaki-ishikawa-thunderbird-account
2020-02-04 15:33 ` Eli Zaretskii
2020-02-05 1:11 ` chiaki-ishikawa-thunderbird-account
2020-02-21 17:27 ` Noam Postavsky
2020-02-22 17:53 ` chiaki-ishikawa-thunderbird-account
2020-04-28 21:36 ` ISHIKAWA,chiaki
2020-04-29 6:55 ` Eli Zaretskii
2020-04-30 2:45 ` chiaki-ishikawa-thunderbird-account
2020-05-20 4:31 ` chiaki-ishikawa-thunderbird-account
2020-05-25 12:15 ` Noam Postavsky
2020-05-25 15:50 ` chiaki-ishikawa-thunderbird-account
2020-06-08 8:17 ` chiaki-ishikawa-thunderbird-account
2021-08-10 16:09 ` Lars Ingebrigtsen
2021-08-11 1:08 ` ISHIKAWA,chiaki
2021-08-11 6:07 ` ISHIKAWA,chiaki
2021-08-11 7:22 ` ISHIKAWA,chiaki
2021-08-11 11:14 ` Lars Ingebrigtsen
2021-08-11 13:46 ` ISHIKAWA,chiaki
2021-08-11 11:47 ` Eli Zaretskii
2021-08-11 13:41 ` ISHIKAWA,chiaki
2021-08-12 7:10 ` Eli Zaretskii
2021-08-15 23:27 ` ISHIKAWA,chiaki [this message]
2021-08-16 0:20 ` ISHIKAWA,chiaki
2021-08-16 11:35 ` Eli Zaretskii
2021-08-20 1:56 ` ISHIKAWA,chiaki
2021-09-17 14:49 ` Lars Ingebrigtsen
2021-10-18 9:00 ` Lars Ingebrigtsen
2021-10-19 7:04 ` ISHIKAWA,chiaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e384638a-8340-b615-778a-877ba8708e85@yk.rim.or.jp \
--to=ishikawa@yk.rim.or.jp \
--cc=39413@debbugs.gnu.org \
--cc=chiaki.ishikawa@ubin.jp \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).