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 14:25:15 -0500 Message-ID: References: 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="16377"; mail-complaints-to="usenet@ciao.gmane.io" Cc: fweimer@redhat.com, carlos@redhat.com, monnier@iro.umontreal.ca, hi-angel@yandex.ru, 45200@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 20:55:32 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 1l7OFQ-00049W-02 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 20:55:32 +0100 Original-Received: from localhost ([::1]:58586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7OFO-0006tt-VC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 14:55:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7Nms-0002XC-Co for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 14:26:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7Nms-0003Su-4N for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 14:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7Nmr-00022U-Vv for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 14:26: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: Wed, 03 Feb 2021 19:26: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.16123803277799 (code B ref 45200); Wed, 03 Feb 2021 19:26:01 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 19:25:27 +0000 Original-Received: from localhost ([127.0.0.1]:38887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7NmI-00021i-Np for submit@debbugs.gnu.org; Wed, 03 Feb 2021 14:25:27 -0500 Original-Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:31268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7NmG-00021Z-M6 for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 14:25:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612380324; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=KFrdeOkd0NtgcrodlOyHjs2e2AEuyyYn7Lg12thKroM=; b=UPa2d5svjUmIS2xEpMWaFoIm+tAtWE+pOqAn0z+a1nS8trWqg4BndDJSGSZAeJfRA2M22d DSABf76H+Rmzi+xPTq2vARkomBwMqcAzrjZI+z2GZzGIj06v85YJ5tMkLygn8aeM4FurQo ZujQxIOWNStWO24M9J5WoHltmDuKCDQ= 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-436-nRWJAYdoOaCTcb4wrzFH3Q-1; Wed, 03 Feb 2021 14:25:23 -0500 X-MC-Unique: nRWJAYdoOaCTcb4wrzFH3Q-1 Original-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B72398710E3; Wed, 3 Feb 2021 19:25:21 +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 4CE891971D; Wed, 3 Feb 2021 19:25:18 +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 113JPG7L000768; Wed, 3 Feb 2021 14:25:16 -0500 In-Reply-To: <83v9b943em.fsf@gnu.org> (message from Eli Zaretskii on Wed, 03 Feb 2021 16:44:17 +0200) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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:199232 Archived-At: Eli Zaretskii writes: >> The problem we're dealing here with is an actual bug in glibc=E2=81=B5. = What >> this implies is that if the fix indeed 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 fact that the bug you reported didn't get any responses in more > than a month, let alone wasn't fixed, could be a sign that not > everyone agrees this is a bug... Right, glibc's malloc maintains a cache of re-usable chunks of memory, for performance reasons. That cache, obviously, costs memory. malloc_trim() flushes that cache and returns memory to the kernel. That has two effects: first, your memory footprint is smaller, but second, your performance will suffer until the cache is refilled. We (glibc devs) don't consider "poor cache performance for my application" to be a bug. A patch which improves cache performance *for most apps* would be considered, but a patch that improves one app's speed at the cost of most other apps, would be rejected. You (emacs devs) need to decide whether you care more about memory footprint or memory performance, and tune malloc accordingly. malloc_trim() is one knob to tune, there are others. But don't say it's a "bug" if our defaults don't match your optimal settings.