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.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Sat, 18 Jun 2022 09:06:18 -0400 Message-ID: References: <877d5mqmkh.fsf@localhost> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25191"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Ihor Radchenko , Mattias =?windows-1252?Q?Engdeg?= =?windows-1252?Q?=E5rd?= , Eli Zaretskii , 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 Sat Jun 18 15:08:13 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 1o2YBQ-0006Oa-Kc for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 15:08:12 +0200 Original-Received: from localhost ([::1]:59720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2YBP-0003f2-64 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 09:08:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2Y9l-0002W1-3Y for emacs-devel@gnu.org; Sat, 18 Jun 2022 09:06:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2Y9i-0007Vs-HH; Sat, 18 Jun 2022 09:06:27 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6A2E580931; Sat, 18 Jun 2022 09:06:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0F3C680385; Sat, 18 Jun 2022 09:06:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1655557580; bh=+pLJ5iPTdR5KGaT2W7jtal8V43aj1MVqedJDP90IgTk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=LQBtyhTpe4OaKbI7+zn0fPKFSAkg8JRCNxOl3mk6dbnLb7pIzu/r5PJvqTTV2L7To SOkFd714oE/ut7fmA05wSUQL4wqouslITcCbyM8C3q5et0RAKE8es4m/AbLEz62q3a 7Ek41Kgw9iixIuG2LI3No4fGOpFXbeIAg+VrGMh2x8mZoxFiZMkWIgzFrrtnfs1GKm lJOz+LLzObR6qZuga1MfTmgY6U28TmguE+4iRg+f3lYK8G4H23jW8Pe2Psfr5dMh+Y fNlUzHQrTV+FC80WHAo8ihb0dfM+7S1uz7MaPTmGj8zhb9NoWEY2vQE6i4V3Z6RzGl Zty4N6Wo4Cc/Q== Original-Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8AB611203A5; Sat, 18 Jun 2022 09:06:19 -0400 (EDT) In-Reply-To: <871qvm16he.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 18 Jun 2022 14:49:49 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:291362 Archived-At: >> Obviously this process ends up with a very large one-step allocation >> which is arguably interesting in itself (I suspect there's some >> GC-inhibition going on there), but the more interesting point >> is that with p=0.1 we get an amount of free space after GC >> (i.e. blocks we can't release, because of fragmentation) that's about as >> large as the next threshold, i.e. about 10%, whereas with p=1.0 this >> amount of unreleasable free space is significantly higher. > As far as I know, we never actually release back cons space to the OS > anyway -- even if we could. But we do release to the malloc library, which means it can be reused for other things (instead of being constrained to only contain cons cells, for example). Whether that library in turn releases it back to the OS is out of our control (and apparently current glibc never does so). >> I think p=1.0 (and the corresponding implication that we use up about >> twice as much memory as the minimum we need) might be an acceptable >> tradeoff (for batch use), but I don't think I'd be comfortable going >> beyond that. > > Right. We can still have the Emacs makefiles increase the threshold for > build purposes even if we settle on a lower general level for --batch. We could, I guess, tho the performance difference between p=1.0 and p=2.0 isn't very significant. Stefan