From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: MPS: User GC customizations Date: Thu, 04 Jul 2024 13:20:44 +0000 Message-ID: <87le2h47kj.fsf@localhost> References: <87v81pbgzi.fsf@localhost> <86a5j1fhd1.fsf@gnu.org> <87y16khvhy.fsf@localhost> <87frspqwhr.fsf@localhost> <87tth5pdqc.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="12651"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Pip Cet , Eli Zaretskii , emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 04 15:19:49 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 1sPMNI-00032a-Dc for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jul 2024 15:19:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPMN1-00083Y-EL; Thu, 04 Jul 2024 09:19:31 -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 1sPMMz-00083K-Jn for emacs-devel@gnu.org; Thu, 04 Jul 2024 09:19:29 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPMMr-0002Tx-AI for emacs-devel@gnu.org; Thu, 04 Jul 2024 09:19:29 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D805B240101 for ; Thu, 4 Jul 2024 15:19:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720099158; bh=X6jJ1nzNygmp3UpGBPe1Wmo9gsplBnfT+H7YYT83PvA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=mxTqLzlt+T346beCBGuaNbjLF8S6XRaGsjRXIkNBOHmEo2kcDW1CZ0nJBtyuo4/Qt zUA/29kSOc8RlLXPq1yrF2Ef4HeS7EfVDR72KQkX0s6HYZdgaEASJ09uCN1W/Kdicg CzjJmKI2EBUd4Bm4f3RHeGxENrNlRuq4B+PuovesL8hQQg5S0lz5oSvB/6duiH3m25 8hq7OXrScRdiUXiloyDakkLh552g+W3ELmsfGRu1CF3/8zH+pGQg19sCj29YkFXpN8 jSWU07/EnNA8GhgbW3Ou4wft/6aJwgTp41c8jZP4HuF4UD5AzVmxHp67Mv+ufrLetm zmf5rAyQyPf0g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WFHKw3FYPz6tsf; Thu, 4 Jul 2024 15:19:16 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de 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, 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:321317 Archived-At: Gerd M=C3=B6llmann writes: >>> igc-step-interval is a variable defined in =E2=80=98C source code=E2= =80=99. >>> ... >> IMHO, this variable makes little sense in isolation. It only makes sense >> to postpone GCs when we also have the means to increase the thresholds >> when to trigger them. Most of the time, GCs are triggered by >> memory-intensive commands. Extra GC on idle would not help those. > > 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. > 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) >> For example, my recent measurement of building agendas displayed 30% of >> the time spend in GC. (whatever this means in the context of our handling >> 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". 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. 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. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at