From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Carlos O'Donell Newsgroups: gmane.emacs.bugs Subject: bug#43389: 28.0.50; Emacs memory leaks Date: Tue, 17 Nov 2020 11:32:23 -0500 Organization: Red Hat Message-ID: References: <87r1r5428d.fsf@web.de> <874kmcvlbj.fsf@mail.trevorbentley.com> <83imasb0te.fsf@gnu.org> <871rgzvbme.fsf@mail.trevorbentley.com> <83lff6zm8f.fsf@gnu.org> <838sb1rrar.fsf@gnu.org> <87wnylm3sw.fsf@oldenburg2.str.redhat.com> <83r1osq96c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35117"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 Cc: 43389@debbugs.gnu.org, dj@redhat.com To: Eli Zaretskii , Florian Weimer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 17 17:34:13 2020 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 1kf3vp-00090G-Cp for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Nov 2020 17:34:13 +0100 Original-Received: from localhost ([::1]:40942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf3vo-0005FB-DN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Nov 2020 11:34:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf3ve-0005B3-Ag for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 11:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kf3vd-0000KG-UA for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 11:34:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kf3vd-0005xP-PH for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2020 11:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Carlos O'Donell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Nov 2020 16:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43389 X-GNU-PR-Package: emacs Original-Received: via spool by 43389-submit@debbugs.gnu.org id=B43389.160563079522832 (code B ref 43389); Tue, 17 Nov 2020 16:34:01 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 17 Nov 2020 16:33:15 +0000 Original-Received: from localhost ([127.0.0.1]:60986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf3ut-0005wC-5T for submit@debbugs.gnu.org; Tue, 17 Nov 2020 11:33:15 -0500 Original-Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:32216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf3us-0005w5-1p for 43389@debbugs.gnu.org; Tue, 17 Nov 2020 11:33:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605630793; 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:references:references; bh=erOQzsveH/M9BZEGhH6Gl3mgYCj+V3jKWk6kHmTWCjk=; b=dEOOiaiapjOEyk73fzEaJtC6lmnyUtVuCMgcBO+YARUk+FvVFSTq9Xd3FfnlkYnfKpGc6z jp/BgD5HT4tH/coLdxP7uCoYqB1kvx60fjq90oSOlaWtSthrzHfCaMY1Hl3EuIcyXPeF0E GWYTVs6PHBZFLEs1k/rbVrUZLzHU3+4= Original-Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-408-dnXTTEcSN3mGXzvjPgs3QA-1; Tue, 17 Nov 2020 11:33:10 -0500 X-MC-Unique: dnXTTEcSN3mGXzvjPgs3QA-1 Original-Received: by mail-io1-f69.google.com with SMTP id l15so4706494ioh.18 for <43389@debbugs.gnu.org>; Tue, 17 Nov 2020 08:33:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=erOQzsveH/M9BZEGhH6Gl3mgYCj+V3jKWk6kHmTWCjk=; b=okpkCrSdhESSCtNdf0FhQnnH4/jOTYAXX8zuB8i1LuXBhSeEAMKa3sQTTJREFYqOxB THw6n7nS+xAots3UwZKc6IGDOH47fz/j3y3OZBE6MT9BJwHfccxUylMiN0JaenuFlUUp +DbPRyLDMBuGAX1iuXB7sATf1FSDn+MOCkkyS2NYXiYyEVMvKQtTDKG5anhWHOBnw0S1 7TBTR82WAVCxvbtgLHRNdwbQdvD3Ek3bfGpQhVJwn6BfP1Gs7XbU2lmo9wTUr6e4if9D RMpIllodRjODkM3cuEiZpejFVVrW9ZZG/kudhsk/5Rkzm8y27f87SUau4tbsCGnnvXh4 lcGQ== X-Gm-Message-State: AOAM531s5/3cjFpGnYfneVmYiXyZMLG0Zm386/UtxYyexl31QHK/nzoT urTiIzKrz5KQBUeYjV37fvUpNKIOom4AUlVpjzVMYD05sFFkF1CxKk/L+bKBPxNitF+wV5Wte3M ElV+gqYZFFwF5OBXQEUgF2G/SI20bpRW92Uye7j2i/Ih21thmUykRT7iNj3Mo3LuS X-Received: by 2002:a05:6638:b30:: with SMTP id c16mr4284663jab.61.1605630789625; Tue, 17 Nov 2020 08:33:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJxlX/G/RV088kx22nYk8unQlHz//IYv97CrWHlPGGJ9zinJahPpKTLlq4RTa8+QhL9MVjqImw== X-Received: by 2002:ac8:5901:: with SMTP id 1mr504960qty.350.1605630751640; Tue, 17 Nov 2020 08:32:31 -0800 (PST) Original-Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id o16sm15354728qkg.27.2020.11.17.08.32.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 08:32:26 -0800 (PST) In-Reply-To: <83r1osq96c.fsf@gnu.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=carlos@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US 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:193554 Archived-At: On 11/17/20 10:45 AM, Eli Zaretskii wrote: >> From: Florian Weimer >> Cc: carlos@redhat.com, dj@redhat.com, 43389@debbugs.gnu.org >> Date: Mon, 16 Nov 2020 21:42:39 +0100 >> There is an issue with reusing posix_memalign allocations. On my system >> (running Emacs 27.1 as supplied by Fedora 32), I only see such >> allocations as the backing storage for the glib (sic) slab allocator. > > (By "backing storage" you mean malloc calls that request large chunks > so that malloc obtains the memory from mmap? Or do you mean something > else?) In this case I expect Florian means that glib (sic), which is a slab allocator, needs to allocate an aligned slab (long lived) and so uses posix_memalign to create such an allocation. Therefore these long-lived aligned allocations should not cause significant internal fragmentation. > Are the problems with posix_memalign also relevant to calls to > aligned_alloc? Emacs calls the latter _a_lot_, see lisp_align_malloc. All aligned allocations suffer from an algorithmic defect that causes subsequent allocations of the same alignment to be unable to use previously free'd aligned chunks. This causes aligned allocations to internally fragment the heap and this internal fragmentation could spread to the entire heap and cause heap growth. The WIP glibc patch is here (June 2019): https://lists.fedoraproject.org/archives/list/glibc@lists.fedoraproject.org/thread/2PCHP5UWONIOAEUG34YBAQQYD7JL5JJ4/ >> The other issue we have is that thread counts has exceeded in recent >> times more than system memory, and glibc basically scales RSS overhead >> with thread count, not memory. A use of libgomp suggests that many >> threads might indeed be spawned. If their lifetimes overlap, it would >> not be unheard of to end up with some RSS overhead in the order of >> peak-usage-per-thread times 8 times the number of hardware threads >> supported by the system. Setting MALLOC_ARENA_MAX to a small value >> counteracts that, so it's very simple to experiment with it if you have >> a working reproducer. > > "Small value" being something like 2? The current code creates 8 arenas per core on a 64-bit system. You could set it to 1 arena per core to force more threads into the arenas and push them to reuse more chunks. export MALLOC_ARENA_MAX=$(nproc) And see if that helps. > Emacs doesn't use libgomp, I think that comes from ImageMagick, and > most people who reported these problems use Emacs that wasn't built > with ImageMagick. The only other source of threads in Emacs I know of > is GTK, but AFAIK it starts a small number of them, like 4. > > In any case, experimenting with MALLOC_ARENA_MAX is easy, so I think > we should ask the people who experience this to try that. > > Any other suggestions or thoughts? Yes, we have malloc trace utilities for capturing and simulating traces from applications: https://pagure.io/glibc-malloc-trace-utils If you can capture the application allocations with the tracer then we should be able to reproduce it locally and observe the problem. -- Cheers, Carlos.