From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Mon, 20 Jun 2022 22:01:05 -0400 Message-ID: References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008fc58a05e1eb98b8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12703"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , Ihor Radchenko , =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 21 04:03:51 2022 Return-path: Envelope-to: ged-emacs-devel@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 1o3TF7-00033v-Ty for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 04:03:50 +0200 Original-Received: from localhost ([::1]:48414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3TF5-0001es-Vv for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 22:03:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3TCl-0007jw-0U for emacs-devel@gnu.org; Mon, 20 Jun 2022 22:01:23 -0400 Original-Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]:45628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3TCi-0004vb-2A; Mon, 20 Jun 2022 22:01:22 -0400 Original-Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-1016409cf0bso16612284fac.12; Mon, 20 Jun 2022 19:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UjBBGAEIoRK/NDXvyPgrCKbBat0D5HvIspkmJ9PYK1M=; b=EIzBHGyiim316GuHU1NX0iC4HX5EvCvd8fy8HchjNtwsFlQqUMUfmgA/Gx3j93HTWD dUWo++9dxZoWGM6ri+p6upvxdxgthN+QEMpl1nNrxt8HHU0MVO7MZYTmWzPCRAsKrrq+ nhgqzCaO3rNn+7hhja7t+T89J08TtoBEbdx7frMYmAyiokK6/nUHAoMWAGedrXJ2ZorE k6mGU3V/VSaPSS9r6a46sm4E/mqLQE+tFccgsy5ygBKP2rOaLMnitvX+9TxD/40Cm9Sj aoLaymR/xxR9aZO0FYtx5GMWkIR/lCSNrjI9Ss3VpvQw6dhWep3ZPOEHUfi12ahyFcRu Pncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UjBBGAEIoRK/NDXvyPgrCKbBat0D5HvIspkmJ9PYK1M=; b=Gy1LLJyNNhv2LLhpv0C+Ht1tRzI4S2Ktlv/EzB3F1p48uDVdHt+yDC/MDnulltWgPV aJlkn0skTtIjyaHpUNHqiJMWtWdBi1P83ho34ZUvRJMqCI2tamg1Vy/qLr0vVy3Lk3qO GvBeM7uH7iSI1MS+cWACzEQpFJDQNQSeZYe3UZpZ9v6F565ehdwQLSoUB15Go76SLnCF 2M1AZR0x9Kg3K9mL2yNQzKW7mMMKs20jTDIsk0hM00q1Klm4u6B1kP8VOeXzB2+nrDT2 /gDYK+BxJcTt1a7L+Dg1tF/YXksydHL9iXX3Q6NnJtMqH/+Pyl2D4iEDJXRruASr4bDb LMhg== X-Gm-Message-State: AJIora/Uj8EF8fU2AxvSwrJzy5b/cvdCCd91YZOm3R3s+iKBCIhLxEsc w8pU9/RFh34QMCpIEq/phaKKO74aKMyVu9chDAJa9jfIAEU= X-Google-Smtp-Source: AGRyM1vcQ51AqIYG2JoE1sxrCbIK0YFMMARfOKnIschvCL2TSILOVbHxp31U3eiSiQPVRbb9aR5f3V1QxXC6IKXE9Oo= X-Received: by 2002:a05:6870:c1d1:b0:101:f706:bf29 with SMTP id i17-20020a056870c1d100b00101f706bf29mr4371804oad.247.1655776876674; Mon, 20 Jun 2022 19:01:16 -0700 (PDT) In-Reply-To: <87o7yozzj0.fsf@gnus.org> Received-SPF: pass client-ip=2001:4860:4864:20::33; envelope-from=owinebar@gmail.com; helo=mail-oa1-x33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291476 Archived-At: --0000000000008fc58a05e1eb98b8 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 19, 2022, 7:05 AM Lars Ingebrigtsen wrote: > Eli Zaretskii writes: > > > AFAIK, that's not really true. We call 'free' and glibc does release > > to the OS when it can. And don't forget that Emacs calls 'malloc' a > > lot not just for conses and other Lisp data. > > Wasn't there a huge discussion about this a couple months ago and the > conclusion was that glibc rarely releases memory back to the OS? That's > why we added `malloc-trim'. > Was there? I see:. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71 but it's a little more than a couple of months ago. I'm pretty curious because if I accumulate a large buffer of trace output (running memory up to 100s of MB), killing the buffer doesn't seem to impact gc time substantially. I would think using mmap-based allocation would make release of memory to the system more likely. But mmap is only used for 64+KiB size blocks, and the trim threshold is 128KiB blocks (shouldn't it be lower than the allocation size?) I'm also interested in the improvement in performance reported in that thread from using the jemalloc implementation. Has that been investigated further? Thanks, Lynn --0000000000008fc58a05e1eb98b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 19, 2022, 7:05 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
Eli Zaretskii <eliz@gnu.org> writes:

> AFAIK, that's not really true.=C2=A0 We call 'free' and gl= ibc does release
> to the OS when it can.=C2=A0 And don't forget that Emacs calls = 9;malloc' a
> lot not just for conses and other Lisp data.

Wasn't there a huge discussion about this a couple months ago and the conclusion was that glibc rarely releases memory back to the OS?=C2=A0 That= 's
why we added `malloc-trim'.

but it'= ;s a little more than a couple of months ago.
I'= m pretty curious because if I accumulate a large buffer of trace output (ru= nning memory up to 100s of MB), killing the buffer doesn't seem to impa= ct gc time substantially.=C2=A0=C2=A0
I would think = using mmap-based allocation would make release of memory to the system more= likely.=C2=A0 But mmap is only used for 64+KiB size blocks, and the trim t= hreshold is 128KiB blocks (shouldn't it be lower than the allocation si= ze?)
I'm also interested in the improvement in p= erformance reported in that thread from using the jemalloc implementation.= =C2=A0 Has that been investigated further?

Thanks,
Lynn




--0000000000008fc58a05e1eb98b8--