From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Sat, 25 Jun 2022 09:08:11 +0300 Message-ID: <83sfntb7hw.fsf@gnu.org> References: <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> <874k0hxb0g.fsf@localhost> <87wndb34qj.fsf@localhost> <875ykpwcjx.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3296"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, larsi@gnus.org, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 25 08:11:46 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 1o4z1F-0000jk-An for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 08:11:45 +0200 Original-Received: from localhost ([::1]:47484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4z1D-0008UG-PG for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 02:11:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4yxx-00072d-DW for emacs-devel@gnu.org; Sat, 25 Jun 2022 02:08:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53316) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4yxw-0005pE-Pr; Sat, 25 Jun 2022 02:08:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=CwTWf9kxGintV6Njiz4tP7Hjiv0PS3pW1r2zeiWk5xQ=; b=PBynUNBf4DXfesEx4+Nl oPItqAi9YcZyi79LhYrVupg1zyvcPLnyatBoCmDZ+6aS0YEeGzVoVC7kqzRVeAEo0t4wa5vWGfsZ+ 5RsAyDlRp7JUdCbRbbhg4BvU1ABwFMn72QvOUyji2wtbgLv4iTZdfHYIM0EpbyANWEFl4HjzIuwcA kUBum7rAO9UjG7TBCnN61jp2kIRs1J78YTJuXxhH7CahtaKytlAE69l9VIqL1xHpHTSjS5bQCxfzj 4aYTIVii7y/gG/EYCCviH8EsLpsqs42tNPLWJJgh82WL5ceSIKDqlj07aiMkWr7YVdECNGVDZ5X9f UmB1g0RkBbG6iw==; Original-Received: from [87.69.77.57] (port=4736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4yxr-0004Jc-Qg; Sat, 25 Jun 2022 02:08:16 -0400 In-Reply-To: <875ykpwcjx.fsf@localhost> (message from Ihor Radchenko on Sat, 25 Jun 2022 13:13:22 +0800) 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:291581 Archived-At: > From: Ihor Radchenko > Cc: Lars Ingebrigtsen , Mattias Engdegård > , Eli Zaretskii , Tim Cross > , rms@gnu.org, Alan Mackenzie , > emacs-devel > Date: Sat, 25 Jun 2022 13:13:22 +0800 > > > Not at all. The general rule of thumb is: the sooner you recover free > > space, the better you can avoid fragmentation. > > Sure. But how does the probability to get fragmentation scale with the > GC threshold? Is it linear scaling or is it nonlinear (I suspect that it > is non-linear)? Can someone quantify it? If we do, it would help to > adjust the thresholds more optimally to balance between GC time and > fragmentation. The answer depends on the C library being used. If you are talking about glibc, there's still the question of the statistics of allocation size distribution, because AFAIK glibc's malloc implementation uses several separate lists to manage the arena, each list for allocations between X and Y bytes, where X and Y are different for each list. And for allocations larger than 64KB we instruct glibc to use mmap, where there should be no fragmentation at all.