From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45200: [PATCH] Force Glibc to free the memory freed Date: Wed, 03 Feb 2021 11:02:22 -0500 Message-ID: References: <83k0rz21dw.fsf@gnu.org> <331805c74fc5d3d412dd2065030b11fa3343710d.camel@yandex.ru> <8a91fc16f93298bca1281b43d6821ae3621376dc.camel@yandex.ru> <7ffacc5f-fc0e-a5f8-104d-2c0ae8e06953@gmx.at> <3f4f8b3034e9f52f48ec520f2732b1687bb24dbc.camel@yandex.ru> <31608795-6155-c7c9-7d94-6024adb0a3b9@gmx.at> <09cc70f14e90f6b13b51b0536fae76e87dfe3f42.camel@yandex.ru> <55be0318-c907-bf9b-d644-d88abb816871@gmx.at> <35163027-a5b7-4a6c-6700-69d34fecf451@gmx.at> <824625557ce288b0cbc3edd66ff730afd479b511.camel@yandex.ru> 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="25453"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: carlos@redhat.com, fweimer@redhat.com, dj@redhat.com, 45200@debbugs.gnu.org To: Konstantin Kharlamov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 17:04:52 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 1l7KeB-0006We-UZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 17:04:52 +0100 Original-Received: from localhost ([::1]:42518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7KeA-000477-Tl for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 11:04:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7KcQ-00023d-MQ for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 11:03:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7KcQ-0004Ys-F0 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 11:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7KcQ-0004tN-Aa for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 11:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Feb 2021 16:03:02 +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.161236815318752 (code B ref 45200); Wed, 03 Feb 2021 16:03:02 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 16:02:33 +0000 Original-Received: from localhost ([127.0.0.1]:38661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7Kbx-0004sO-B7 for submit@debbugs.gnu.org; Wed, 03 Feb 2021 11:02:33 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7Kbv-0004s7-Ca for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 11:02:31 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BCFC9440981; Wed, 3 Feb 2021 11:02:25 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4BD1844096F; Wed, 3 Feb 2021 11:02:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1612368144; bh=QNI1cI1t0eioy4SY2k2V6zeWp0/h1/n1uX7BFS+/G4o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=T+ywGqW0mRlNiJwf7YBYkiv6rqd6/1g0kwIEbukVAjpDcjpcRcG3C27rVmwxp6np1 BmRIW9oBe4TBA3SDRPatPCMojhUTcmDxihhIhWNn2n2r6ade4fzHhAvemMBI6bIAdb 6hA0+EITqoTukymdhkO/N3asfyH8GwiQ/wuG5gileK9iD8mdU73neiIGs4Q/8Cwjvo zYe42WKYhFqtychUPSS+8UHAVaVHMELpQrM/fVOaSc7vgB4pgmsho5KuqjHX1PAFTC PZIQfu2fWnUYi/9p3DIcaD6JvfcAVEIajk3sDs5Qif+bOFgLvXJ2+ZpXOmI4oIqxJo Pp3rNdgbqiLDw== Original-Received: from alfajor (76-10-182-85.dsl.teksavvy.com [76.10.182.85]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 020651202A7; Wed, 3 Feb 2021 11:02:23 -0500 (EST) In-Reply-To: (Konstantin Kharlamov's message of "Wed, 03 Feb 2021 18:29:41 +0300") 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:199210 Archived-At: > To answer you question in another email about memory benefits given defau= lt > Emacs settings: well, today I tried creating a testcase that would reprod= uce > problem with default settings, but haven't really succeeded at it. I have > a testcase where Emacs without the patch has =E2=89=8820M more memory tha= n the one > with the patch, but that's pretty small difference, and offhand I didn't > manage to get it increased any further. Thanks. At least that seems to indicate that glibc does its job properly for the way we normally use it. > So, I'm thinking of wiring the functional of memory trimming to on-idle > hook, without possibility to disable it. That seems hard to do (luckily), since AFAICT idle hooks only exist via `run-with-idle-timer` and those can always be disabled with things like `cancel-timer`. > Given how small performance impact in this case would be, I see no > reason to even implement an option to disable it. > Thoughts? My main thought is that if `malloc_trim` indeed makes a significant difference, it's a sign that Emacs's own code did its job (it called `free` as it should) and that the problem is in how glibc decided not to return the memory to the OS. That's a behavior that can (and will) change over time outside of our control. So calling `malloc_trim` every time I stop typing for 10s, just on account of "maybe glibc didn't reclaim quite as much memory as we'd like this time" doesn't sound very appealing to me. It sounds like an ad-hoc quick hack. I love being able to use ad-hoc quick hacks, but I don't like enabling such things by default when the only use-cases where they're known to be useful are fairly specialized (and discouraged by Emacs maintainers ;-) So I think we need more info: do the glibc maintainers consider it normal for glibc to behave this way? Why does it behave this way? Would the equivalent of `malloc_trim` happen anyway "at some point in the future"? E.g. If you create a test case where you disable GC, let the memory use grow to 1GB, then reset the GC vars to their default and keep using Emacs modestly, will the memory ever be returned to the OS or is an explicit call to `malloc_trim` really indispensable? But until we get all the answers to these questions, we can already install the code that exposes `malloc_trim` to ELisp. Stefan