From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Devlin Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 14:23:27 +0900 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87h66ng4bf.fsf@protonmail.com> <3A7135F0-64AD-4577-BDA7-ACE1E60B7364@toadstyle.org> <87jzbid6hm.fsf@protonmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.113.1.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_994CE254-A838-4250-B2B2-1F696B063205" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 13:00:28 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tSERe-0004kc-IL for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 13:00:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSEQw-0006df-4o; Mon, 30 Dec 2024 06:59:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tS8Fl-0003zJ-26 for emacs-devel@gnu.org; Mon, 30 Dec 2024 00:23:45 -0500 Original-Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tS8Fh-0001Ta-KS for emacs-devel@gnu.org; Mon, 30 Dec 2024 00:23:44 -0500 Original-Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-2167141dfa1so110741965ad.1 for ; Sun, 29 Dec 2024 21:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toadstyle-org.20230601.gappssmtp.com; s=20230601; t=1735536219; x=1736141019; darn=gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=InEbgFNnBAu21vYT2GeNKewDZPTpkuQQZU2Yz+POX/M=; b=V7AVVkW58rbLWWc4uudRAS+3mDasAAwivZXOD2psv+iJNwWreKE+IphaD1Aub+D1+R GLV+dklYbL3JTobscFNrffO/xTLy+pk/CpU1LsE2ecOUTuTBF1LZEv/XylKvgjpnZ9aw ow5C4PatwkuA76eFn3bm3Aff6/bXcpWXnVwSzvIx+xsgV9JFs0PGYjZ0hQ1mQpAiW9Bg apvIwT3GW+f8NAUgjWLIU2EEu7EV8zOId537N/5iJLpZWrt2fhZxHWtto8ey6QtXMm61 GtM0AI4Pq7Mu/zhhIBd3v5JWL+EJ0g8/adQ0O22UyCS2MpdWGBIWzd6fXotSN/f68V/3 LsDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735536219; x=1736141019; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=InEbgFNnBAu21vYT2GeNKewDZPTpkuQQZU2Yz+POX/M=; b=sr88omRmWLzDZOt/CmZg9pk5CnTf0uwinPRAuKHMUCknGHajsTGxh83slr2nNJo9Nu B9eVFiiN92DH2gx40zQvaMDGxer69UCPfN4BQW6kpGBrINErQq0R7F5fvsQu8SqAOcA1 itXx2TP0mw2gKOy8ye2GZJeO760iMF92r5H2mutvLiYEcpBgFptGQ/EF1Gnqc0EqYucb YBwxHc0TDJdQ/A8SCcbi4QsOZNLaSEr/Xzv0S89ImQ82i+hNfynR5L3aQupYBEQychkQ 5v1N2xZ+MqjoKOCdGD6b//yDT/U9iLLch9JnpdEoCsa64A2OJLBun8adJ2+pcSx2ig7Z DhlA== X-Gm-Message-State: AOJu0Yz3BHfus7H+lclabPNMM8D/ifkQBDh6cKajmNeXWVWHXYr8wF// 7LzXu7oAFyBSWCCLPYxnH8J9OMraxVPMhtOW4soTNyzTUWpmn6YoGxOXXHapz/4= X-Gm-Gg: ASbGnctsIiH/jGgWXMIqD1r+ZUFkClepEYPCvl3ORa8G9XvgLF51hU2UhXG9fB3ntB4 MnuAe5J0kd5a+uB6FVfq9x5VpSoEsAHZJPFu5WooBgIXc1Y4zXzH5a1lpCAYASAM1FPCM6JtXA1 hRIb5yY+Tp+Nx3YL9FjTKN3EtOjlmG+2eQ2PSsgVE5mY37u6CfkHvtjDvXzP0fJZkwxotUHmiSn HCeSOO7H3c42weVrCRZlZbhmHNvlaF3bEbRLLnU8o6TupWodCflsv2kIKILjlGAxWBXVvKpy+wP HKToYBPEUZCTlhQyqwkzda4Nn2muNTb/y1F2RAEN X-Google-Smtp-Source: AGHT+IGr7tS6n27NMyOgqJ0/Dq5d0A2xhKwV7OlLMusH6ZQE/1uKpLPEdPTVOaonU0rHKeDTivKm0A== X-Received: by 2002:a17:902:da8e:b0:216:6a4a:9a47 with SMTP id d9443c01a7336-219da7effd4mr606747755ad.21.1735536218736; Sun, 29 Dec 2024 21:23:38 -0800 (PST) Original-Received: from smtpclient.apple (111101095029.userreverse.wvs2.kddi.ne.jp. [111.101.95.29]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-842b17273dasm16902714a12.19.2024.12.29.21.23.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Dec 2024 21:23:38 -0800 (PST) In-Reply-To: <87jzbid6hm.fsf@protonmail.com> X-Mailer: Apple Mail (2.3826.400.113.1.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=spd@toadstyle.org; helo=mail-pl1-x629.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 06:59:40 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327409 Archived-At: --Apple-Mail=_994CE254-A838-4250-B2B2-1F696B063205 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 29, 2024, at 9:22=E2=80=AFPM, Pip Cet = wrote: >=20 > "Sean Devlin" > writes: >=20 >> Hi Pip, >>=20 >>> On Dec 29, 2024, at 1:29=E2=80=AFAM, Pip Cet = wrote: >>>=20 >>>> I'll try to come up with a patch. >>>=20 >>> This should provide some data (on stderr) about which signals we = delay, >>> and for how long (the "delayed" messages). It also includes some >>> information on additional points at which we can detect whether = signals >>> are pending (the "delaying" messages); it's probably safe to run = them at >>> that point, but the code might need some changes because other = signals >>> (or even the signal in question) might be legitimately blocked when = we >>> reach that point. >>>=20 >>> If the "delaying" messages indicate acceptable (initial) delays, we >>> might get away with simply calling gc_maybe_quit more often. If = they >>> don't, further fixes will be necessary, or we need to find more such >>> points. >>>=20 >>> On POSIX systems where we can spare an additional signal, we can run = a >>> separate thread to ask us to retry running signal handlers when the >>> arena lock might be available again. >>>=20 >>> Or we could move to a separate thread for slow-path allocations. >>>=20 >>=20 >> I=E2=80=99ve built Emacs with your patch. After running Emacs -Q for = a few minutes, I can confirm I see a few log statements: >=20 > Can you try setting igc-step-interval to a small float value, like = 0.05 > ? As long as it's just a few messages, I don't think it'd cause > significant problems, but maybe enabling the background work would do > something. Sounds good, will do. >=20 >> Please let me know if there are any particular tasks you=E2=80=99d = like me to try, or if I should just collect the logs in the background = during general usage. >=20 > Repeatedly hitting "s" in an M-x igc-stats buffer should cause more > messages, but that uses IGC in an atypical fashion, so I'm not sure > that's actually useful data... Well, I can definitely make it log a bunch of messages either by running = the profiler or by spawning subprocesses. Is that helpful by itself, or = do I also need to generate garbage for collection? >=20 > Thanks! >=20 > Pip --Apple-Mail=_994CE254-A838-4250-B2B2-1F696B063205 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 29, 2024, at 9:22=E2=80=AFPM, Pip Cet = <pipcet@protonmail.com> wrote:

"Sean Devlin" <spd@toadstyle.org> = writes:

Hi Pip,

On Dec = 29, 2024, at 1:29=E2=80=AFAM, Pip Cet <pipcet@protonmail.com> = wrote:

I'll try to come up with a = patch.

This should provide some data (on stderr) = about which signals we delay,
and for how long (the "delayed" = messages).  It also includes some
information on additional = points at which we can detect whether signals
are pending (the = "delaying" messages); it's probably safe to run them at
that point, = but the code might need some changes because other signals
(or even = the signal in question) might be legitimately blocked when we
reach = that point.

If the "delaying" messages indicate acceptable = (initial) delays, we
might get away with simply calling gc_maybe_quit = more often.  If they
don't, further fixes will be necessary, or = we need to find more such
points.

On POSIX systems where we = can spare an additional signal, we can run a
separate thread to ask = us to retry running signal handlers when the
arena lock might be = available again.

Or we could move to a separate thread for = slow-path allocations.


I=E2=80=99ve built Emacs = with your patch. After running Emacs -Q for a few minutes, I can confirm = I see a few log statements:

Can you = try setting igc-step-interval to a small float value, like = 0.05
?  As long as it's = just a few messages, I don't think it'd cause
significant problems, but maybe enabling = the background work would do
something.

Sounds = good, will do.


Please let me know if there are any particular tasks you=E2=80=99d = like me to try, or if I should just collect the logs in the background = during general usage.

Repeatedly hitting "s" in an M-x igc-stats buffer should = cause more
messages, but that uses = IGC in an atypical fashion, so I'm not sure
that's actually useful data...

Well, I can definitely make it log a = bunch of messages either by running the profiler or by spawning = subprocesses. Is that helpful by itself, or do I also need to generate = garbage for collection?

Thanks!

Pip

= --Apple-Mail=_994CE254-A838-4250-B2B2-1F696B063205--