From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: DJ Delorie Newsgroups: gmane.emacs.bugs Subject: bug#45200: [PATCH] Force Glibc to free the memory freed Date: Wed, 03 Feb 2021 22:38:04 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: fweimer@redhat.com, carlos@redhat.com, hi-angel@yandex.ru, 45200@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 04 04:39:17 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 1l7VUD-0002s9-Ko for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Feb 2021 04:39:17 +0100 Original-Received: from localhost ([::1]:35762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7VUC-0000U8-6h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 22:39:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7VTx-0000U0-Uo for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 22:39:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56069) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7VTx-0005nm-Ni for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 22:39:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7VTx-000858-J6 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 22:39:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: DJ Delorie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Feb 2021 03:39: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.161240993731053 (code B ref 45200); Thu, 04 Feb 2021 03:39:01 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 4 Feb 2021 03:38:57 +0000 Original-Received: from localhost ([127.0.0.1]:39382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7VTt-00084n-3X for submit@debbugs.gnu.org; Wed, 03 Feb 2021 22:38:57 -0500 Original-Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:29383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7VTq-00084Y-IE for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 22:38:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612409933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=c40yvS0b5LKCGZXos/gmGw4miP9/1IvgbQ7sTHUaA68=; b=MFnkFcj/h6s0K9rYyruP7+1YmvP/jN9+dbPChgm546/3g5OOl8GsdVTAkwcvf2RNHq0PSg uORO/qpSfV7m+6djzo97CndYSsAtqVK8qydiQ1pImmhbSAB5+2x3TDVkFDW75MYtcoT4sf vVTFdieXeMKpj5EgJu7kCBpT3k0Tqe4= Original-Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-175-emu34IGNMSWLr8kBJTCHtA-1; Wed, 03 Feb 2021 22:38:11 -0500 X-MC-Unique: emu34IGNMSWLr8kBJTCHtA-1 Original-Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4A6F015720; Thu, 4 Feb 2021 03:38:10 +0000 (UTC) Original-Received: from greed.delorie.com (ovpn-114-77.rdu2.redhat.com [10.10.114.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F127D722D1; Thu, 4 Feb 2021 03:38:06 +0000 (UTC) Original-Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.14.7/8.14.7) with ESMTP id 1143c4E3000388; Wed, 3 Feb 2021 22:38:05 -0500 In-Reply-To: (message from Stefan Monnier on Wed, 03 Feb 2021 22:26:29 -0500) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dj@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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:199261 Archived-At: Stefan Monnier writes: >> No. Even the tiniest allocation still in use at the top of the heap >> locks the entire rest of the heap into memory. > > Hmm... then I don't understand: the user who reports the problem with > Emacs claims that calling `malloc_trim` reduces the PSS size of > Emacs tremendously (from 260MB down to 60MB). > > If `malloc_trim` can't release memory other than at the top, then how > come glibc didn't recover those 200MB on its own (e.g. it seems 200MB > is well beyond the default value of M_TRIM_THRESHOLD)? Well, let me make up a case that "works" and you tell me if this is common in emacs. Consider you've spent the day doing normal things and your heap is at 100 Mb. Now you do something memory-intensive for a few minutes, and stop, and gc runs. That "something" allocates a lot of memory, but it's all going to be at the top of the heap - aside from whatever fits in the first 100 Mb. It's all released, and GC free()'s it all. malloc_trim() at this point would coalesce it and return it to the system. As long as gc runs between each type of "task", a high-memory task will be trimmable because GC would have freed all that memory and it's all together at the top of the heap. What would cause a problem is, say, if in the middle of running a high memory task you *also* load a font or something and *that* locks the top of the heap.