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: MPS: commit limit Date: Tue, 16 Jul 2024 18:54:51 +0300 Message-ID: <86msmhgwms.fsf@gnu.org> References: <7PXYgVu5A8knQy6Q03cbm6FjO7s022nC0cqCRtUDhQBgA8ZrpLqmoVRgxD8moCTJpB_52ngFaJnW5JIflrzpHe09WcmbRqiHIdWQZE9kQgU=@protonmail.com> <87tth1xm4n.fsf@gmail.com> <87msmtxkpy.fsf@gmail.com> <87ed85xj67.fsf@gmail.com> <8734olxcdj.fsf@gmail.com> <87bk2xweng.fsf@gmail.com> <86r0btgxwj.fsf@gnu.org> <878qy1uyui.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 16 17:57:24 2024 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 1sTkYO-0004mm-PN for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Jul 2024 17:57:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTkWh-0000TV-P0; Tue, 16 Jul 2024 11:55:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sTkWd-0000CR-0G for emacs-devel@gnu.org; Tue, 16 Jul 2024 11:55:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sTkWb-0007am-0m; Tue, 16 Jul 2024 11:55:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OJePEZ1by1S4IvvuZBjaDBXRKcNUCvnsmLjKJH9mwr0=; b=KPgYZOP3wiFq btHkm28OMApDLMdj9YfSRFRr0HBTU1OkM468lC9uIsasFCt6GbDm3nms+tFW3indummpcp475ZLpo Zds00rr5HPrOWZueC0Dum1Uh0fh99ky1VoTG7JLJp/ORFwS4EYdJESM/oHs542AmgH7m/AuWQa53A Hr0rgBN1H2CWX2O/UML5pnZtiRaMbSVGRG3KmDKcnnVEfoUoHmjzLcJJb4gH4umRp9cz0uqylc9CB GFn0I+Z0N27DUYQF6GzyCgqBiQO0JOk1wnSJOXfqtE4bNEKk+4lfEI9x7KNUpNhBSRDHL62XCX9x6 oZxDoE71THnQ5k4yeHDFiQ==; In-Reply-To: <878qy1uyui.fsf@gmail.com> (message from Helmut Eller on Tue, 16 Jul 2024 17:43:17 +0200) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321718 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, yantar92@posteo.net, > emacs-devel@gnu.org > Date: Tue, 16 Jul 2024 17:43:17 +0200 > > On Tue, Jul 16 2024, Eli Zaretskii wrote: > > >> This patch adds a igc--set-commit-limit function. It doesn't fix the > >> problem with the assertion. People who use the hot MPS build will > >> probably see a normal memory full error and probably have to quit soon > >> after that. The others see the failed assertion and abort immediately. > >> So the end result will not be much different. > > > > Is this a debugging aid? > > Yes, that too. > > > If so, please say that in the doc string. > > It's an internal function. Only people who know what they're doing > should use it. I doubt the number of people who match that description (i.e. understand enough what the limit does to use it wisely) is large enough to justify its existence. VM concepts are not easily understood and even less easily translated to practical terms of using a modern system. Especially when memory is allocated by sophisticated libraries such as glibc, which have their own ideas of when and if to release memory to the OS. IOW, we are giving unsuspecting users a too-long rope they can inadvertently hang themselves. > > If that's not the reason, then why would we need to limit the amount > > of memory MPS can commit? I think we generally let Emacs use as much > > memory as the system is prepared to give it, no? > > It also helps to avoid thrashing on machines that don't have many GB of > unused RAM. There's ulimit, and if someone wants to avoid thrashing, they can do that already. OTOH, hitting thrashing is much safer than running out of memory -- the latter makes the risk of losing edits much higher. So I think this should be limited to testing, and the doc string should warn against using the function for anything else.