From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: User GC customizations Date: Thu, 04 Jul 2024 16:45:36 +0200 Message-ID: References: <87v81pbgzi.fsf@localhost> <86a5j1fhd1.fsf@gnu.org> <87y16khvhy.fsf@localhost> <87frspqwhr.fsf@localhost> <87tth5pdqc.fsf@localhost> <87le2h47kj.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23399"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , Eli Zaretskii , emacs-devel@gnu.org, eller.helmut@gmail.com To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 04 16:46:35 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 1sPNjG-0005su-Ih for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jul 2024 16:46:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPNiR-0001jb-Bf; Thu, 04 Jul 2024 10:45:43 -0400 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 1sPNiP-0001i5-95 for emacs-devel@gnu.org; Thu, 04 Jul 2024 10:45:41 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sPNiN-0002Bn-Gv; Thu, 04 Jul 2024 10:45:40 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3679e9bfb08so421659f8f.1; Thu, 04 Jul 2024 07:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720104337; x=1720709137; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5uYTIeuniTjm/N3Ghijan1lcKBEUHBqUpCdhi1aiYvg=; b=AqA9S8UvsAU0dJzmTqzcfpaHVaxDaOGUp60PaXDRmuA4Lt49OomWacM0TL18wdXOuo SBcd1p6qaVetvl8zG3OhDzpJyXXKewulbiTmQyDVE4KbdPbCSsDHH1Xaai5ilajLpPnp 2A18dwIUwA9qX/JmcF9f8f9oS59fjWxeXmseHGQ29uF4t0lUNLy2bA4Mju5g6+jSXxig TR45GMkx5MIXyLs6qfUWLZxFmLPkYCG9unhburko5yCNb2FcM6PKiSKkWrMPlMMHRpzo oiyd6ICUjmxHJenLZZarjeaYLrpmdtmZjXa+8nTuqjuhKSFvd/0bYY2MgLP3kB2etMeq xyhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720104337; x=1720709137; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5uYTIeuniTjm/N3Ghijan1lcKBEUHBqUpCdhi1aiYvg=; b=EriLQb18nt0AP/B43TSStfWVOKi2HC56Fb5FbNw1zqBAjfwUFPX0SW5lRvWb+uzLCD xdnu0RRnzKUc9/6jrUs7aG+omqUSbhEtgeOMpH8NYP8IsiBRG3OEIb7ukifzBjQ57LzM k6oGNXJ35f2DOF7sCu11n+V4/SexieqLosDJb6qJszKhp5Ev2K5nUGkvB6GHxQKYaiIr 86QgRPqZZmhAnKx53VcLU4Jy3DTdMln75CFoKNbtzVqu3LfCVcy+7UtqEW2xF8EkSe7t DHFIFF6GGZj8dEhdSElqT/egVjcc+MaGZ01iJoob52ZEYbdR60xDHb6jQPCTt38yAeA3 b+Sg== X-Forwarded-Encrypted: i=1; AJvYcCVOZm/LQvAqHknmsacB1BmEzXiAGjqA+BtGSr7pxwVkYonVYOipI1IxZbdBH2qdbEnn4yXq5wAnaaL7/o4qoXPlF92CGachtAB/+2WHv7ssb38= X-Gm-Message-State: AOJu0YwQKo8PD61evNYGDKMw1vxYYK1vNIpOcxlEQboxLXEIM/9/k0Dr 0BZKK2UxB0DNMUxeGmvZ6UZ86oU8FvpHd6CoZKSi4wCn/UhC+STf X-Google-Smtp-Source: AGHT+IH7lg3bS4HxkR5OlrGk40U9A4QSBJqfZMxGLwpMeqPZnZaCvfOfCXoBuyRYQwAoGEU2R5Y0mg== X-Received: by 2002:a5d:54ce:0:b0:367:8a2d:b354 with SMTP id ffacd0b85a97d-3679f6f14bemr1432852f8f.14.1720104337524; Thu, 04 Jul 2024 07:45:37 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36fa8.dip0.t-ipconnect.de. [217.227.111.168]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3678fe13ef4sm5410559f8f.117.2024.07.04.07.45.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jul 2024 07:45:36 -0700 (PDT) In-Reply-To: <87le2h47kj.fsf@localhost> (Ihor Radchenko's message of "Thu, 04 Jul 2024 13:20:44 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=gerd.moellmann@gmail.com; helo=mail-wr1-x435.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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-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:321322 Archived-At: Ihor Radchenko writes: >> Define GC, so to speak, and define what triggering the GC means in a >> concurrent, incremental GC :-) > > AFAIU, the points of interests from real-time performance perspective > are (1) when MPS has to pause the threads to do its job and how we can > tweak it; (2) how long does it take to scan the arena to allocate new > objects (synchronous process) and how this time is influenced by MPS > settings. Right. Alas, we don't have something for that. (And I don't know how to do it either.) > >> What this variable does is give MPS notice that the client is currently >> idle and it might be a good time to do some work. > > Without understanding what effect setting this variable has on the Emacs > responsiveness, it does not seem very useful. (Exactly because MPS is > concurrent) That was kind of my point. We can use idle time for using this variable and see what effect it has, especially in interactive use. Sorry if that wasn't clear. I'm personally trying 0.1 (100ms) here at the moment. >>> For example, my recent measurement of building agendas displayed 30% of >>> the time spend in GC. (whatever this means in the context of our handli= ng >>> of SIGPRF) >> >> Exactly, whqt does it mean? And if we don't know, why is it an example >> for anything? > > AFAIU, on master, SIGPROF handled while our vanilla GC is running > will record it. In contrast, on scratch/igc, SIGPROF will put all the > time when igc_busy_p () is non-nil into "GC". Right. And I wonder if that simply is because MPS is doing stuff in its own thread. > And igc_busy_p is not only non-nil when MPS is pausing Emacs to do its > job, but also during object allocation. So, on master, profiler "GC" > field records real GC pauses, while on scratch/igc "GC" field is GC > pauses + new object allocation. The docs say -- C Function: *note mps_bool_t: 129. mps_arena_busy (mps_arena_t arena) Return true if an *note arena: 16. is part of the way through execution of an operation, false otherwise. =E2=80=98arena=E2=80=99 is the arena. Note: This function is intended to assist with debugging fatal errors in the *note client program: d0. It is not expected to be needed in normal use. If you find yourself wanting to use this function other than in the use case described below, there may be a better way to meet your requirements: please *note contact us: d8. What "partly through an operation" means is anyone's guess at this point. Someone would have to consult the sources. The docs don't say what you are suggesting, from my POV. > My figure of 30% says that igc_busy_p () is for 30% of CPU time, which > is a significant number. But it is not very useful unless we get some > idea about which part of it is memory allocation and which part of it is > MPS pausing all Emacs threads. > > Ideally, we should also have some way to get the allocation times on > master. Then, we can compare them directly. Maybe it would be interesting what the meansurements look like on macOS, where the check for igc_busy are not needed in the SIGPROF handler. Anyway. I'm not working on this, I just wanted to promote the variable as a knob that one can play with.