From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#45200: [PATCH] Force Glibc to free the memory freed Date: Wed, 3 Feb 2021 10:35:48 +0100 Message-ID: <31608795-6155-c7c9-7d94-6024adb0a3b9@gmx.at> References: <83k0rz21dw.fsf@gnu.org> <331805c74fc5d3d412dd2065030b11fa3343710d.camel@yandex.ru> <8a91fc16f93298bca1281b43d6821ae3621376dc.camel@yandex.ru> <7ffacc5f-fc0e-a5f8-104d-2c0ae8e06953@gmx.at> <3f4f8b3034e9f52f48ec520f2732b1687bb24dbc.camel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40816"; mail-complaints-to="usenet@ciao.gmane.io" Cc: carlos@redhat.com, fweimer@redhat.com, 45200@debbugs.gnu.org, dj@redhat.com To: Konstantin Kharlamov , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 10:37:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1l7Eb8-000AQg-0L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 10:37:18 +0100 Original-Received: from localhost ([::1]:56976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7Eb7-0005ER-2L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 04:37:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7Eas-0005ED-72 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:37:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7Ear-0001al-Vj for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:37:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7Ear-0005Id-SL for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Feb 2021 09:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45200 X-GNU-PR-Package: emacs Original-Received: via spool by 45200-submit@debbugs.gnu.org id=B45200.161234496620287 (code B ref 45200); Wed, 03 Feb 2021 09:37:01 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 09:36:06 +0000 Original-Received: from localhost ([127.0.0.1]:36825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7EZy-0005H9-EY for submit@debbugs.gnu.org; Wed, 03 Feb 2021 04:36:06 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:50221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7EZu-0005GW-OM for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 04:36:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612344950; bh=Hi++wHhZeWRRvBpXCMBZF86eqHyManfK4/IPeCJWUu8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=AqbTVPyI5YIISXIxFHnaRjyWDkw9fFvfRypOQ+E1gdqnOkDHUu0MqqN453IKOlnyV b9JdaWbU5xQSVqHpL8TRVX3eJmP4is0wrgE7LL1Cy1zGVMbfvAEfwB5IbbG51UFSjH 65AwnFF6LScC2zMuAUZ41bHy6/aNIomRgMfa+rwc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([46.125.249.123]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKKUp-1lNNJh001H-00LpGy; Wed, 03 Feb 2021 10:35:50 +0100 In-Reply-To: <3f4f8b3034e9f52f48ec520f2732b1687bb24dbc.camel@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:0S+9JcfZRkETxrIH/o4siBzOp++Q549ANPfReUxUpzGrGeIxFY3 58AAa6fbY0u2lKQlBgnLPCh2N+gPq3Ll350Hbf0yNl8L5GtxGIePE3mFol92L2fOiGWdsBE r2Q72TIkBg50WlraNpLtHq9P+F1J6RXHLNMDNYbVVSaa5ryAfWhy9Ibxa+iwZUzWC4I8MwP 1/k0t4xVWUl3cHLgAEh1g== X-UI-Out-Filterresults: notjunk:1;V03:K0:SokkLOwCKdE=:ZjOJRe/ymgQEHLc0w+3wt3 YOBYVmJU1jWh9V4u5jq83uDK4XWxe3Z9pac6KPCNI8VovhbsHR54ih6XR/u1Tw/c+UhCSn57Y 3V2nAJZLI58Bd8S6px1Ksz22ACLo0ClMtcKLHChReN4ocmS3upNqAlo+LzWjbCDw4S6IdVO3O X069wVhD1JtW/bhs/KEYVyOzRIw8fr2DJiUAnwOQUPijUbdZsO41BOXTnlF6Lk7fe8wbq8eBh HoxptD3uE36jgngB1mvZnflzP7gyfk1LZ+UienzG71vECcdy0pYSDZeeIU4O1vzReh0gQbTrw V+r3t8hvRHhVnYFFj46B7fL2on4fHf5k/NYL3GvnevPsxUcbDnPVmt8muJU/cahTvS85OU9Ew /aQB00JorvOTJXrctPLvTNOchEPxBfkNejZ0oEJ9IhaPc5yusZ+9tX4p4MIXuATCzgyhptE7Y geehNmf51wnPcMBFrSrPLQ3nuqmd/kDqknV3JXUX4nOWgWLMXJYgxP9QPW7ScHA5d3hq8S9oT 40X7c52VJMkH4rwwZzKC3in7IuA9UZZ7mNwMDi4Y5D1KIJQ6BSnpUTdqEpfPKt5+Y8BopJRSx TaH1Xx94uzzMJhPm2WXGEYbLNBQIeLEqIGoH1L+nVprK15yJYwnZe1+sfK5MPg94imQZL4a35 z+8waSyIeahdEBuURCZobuXy7iLS9FsqG9VUqY4v+yfFLZgn3VMxjSKClz9zR5WN9Sog75bID BWgy9LqOl8rqTVzhndKf6THVPOCB5vSjRRl8QhSMYQqqy9mFyV+6YFuG3QrQ9N4vrlR9ueRL X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:199182 Archived-At: >> Does anyone really disable GC and get away with it? > > Sure. There's for example this post=C2=B9, which is probably where I g= ot the idea to only run GC on idle from. The question is highly upvoted, = it has 4k views, and the only positive answer basically says "it's okay a= s long as you got memory" (well, I got memory), and notes that there's al= so a point in only disabling GC during startup. Similar advice to only di= sable it during startup has this pretty upvoted reddit post=C2=B2 > > Here's another example=C2=B3, except in this case the author only disa= bles GC while they're inside minibuffer, and enables it back upon exiting= =2E This then got propogated here as well=E2=81=B4 > > On top of that, there are countless advices on just increasing the `gc= -cons-threshold` (not inifitely increasing, just making some sane larger = value), that would surely reinforce an idea of just making GC run only on= idle, if one ever comes across such advice or just figures it out. What I meant was if people really disabled GC for the rest of their session and got away with it. But that was only a rhetorical question to which the answer is clearly no. All the examples you cite have a culprit - an application that produces too much garbage. Identifying those applications would be much better than working around them by disabling GC, for example, while a user is in a minibuffer dialog. That latter case even must have an easy to identify responsible, just that nobody cares. And remember that every cons eventually collected must have been allocated first. We always pay twice here. > First of, so far the impact seemed to be small. If one ever comes to > blame the new feature, they surely should have actual measurements to > support that hypothesis. Hardly. Sometimes we're lucky as in the "The Emacs master is much slower than the emacs-27 branch" thread. More often we're not. > Second, most importantly, what `malloc_trim(0)` does is it restores > the correct behavior. I mean, what's the point of ever freeing memory > if it's not freed, right? The problem we're dealing here with is an > actual bug in glibc=E2=81=B5. What this implies is that if the fix ind= eed > hurts performance someplace, well, then it's that this place requires > additional performance-related fixes. As opposed to just ignoring the > bug because of performance got somewhere decreased. Things like, > changing the slow algorithm, or modifying GC behavior for specific > usecases=E2=80=A6 The important use case IMO is: - A user detects, maybe after many hours of use, that memory consumption increases. - The user switches on your option and if memory consumption now decreases, there's at least a first workaround. Personally, I never care about Emacs consuming RAM. On my machine, Firefox dwarfs everything else in this regard. martin