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: master 5c532fe303: Recommend that the user turn off memory overcommit Date: Fri, 08 Apr 2022 22:59:20 +0300 Message-ID: <83h7739wiv.fsf@gnu.org> References: <164941780605.21656.13343783431945268284@vcs2.savannah.gnu.org> <20220408113647.815ACC051D6@vcs2.savannah.gnu.org> <87ilrjemk7.fsf@telefonica.net> <874k33snvb.fsf@yahoo.com> <87lewfbsa0.fsf@ditto.jhoto.spork.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26653"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, ofv@wanadoo.es, emacs-devel@gnu.org To: Brian Cully Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 08 22:00:04 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 1ncum3-0006gf-U4 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 22:00:04 +0200 Original-Received: from localhost ([::1]:35294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncum2-0007lC-7c for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 16:00:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nculC-00074X-Nk for emacs-devel@gnu.org; Fri, 08 Apr 2022 15:59:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nculB-0007Pe-RF; Fri, 08 Apr 2022 15:59:09 -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=Ay0LkyTwIKL4kbB2QI/vkGOfwRZhY+Oaex7qbxN4rYU=; b=d1filr6VblBZtCpXE20D 54mlrScL5MdBDAs9VF7cR+dERj/gpRrBAW/PmZWFGI3hxWOxp+oBLvc2gOI53loAgUKnKHxBn69wH IszcNazBRoQa+lFYwWhuKOeAyUTknuImuQSmN0PILO13KtePFDE8RKBuBWGcTiT7lzx23CPJ/rDpX Is+LOlAtQjsZwJ84JClklQHRX7ahpRwnlGVX72JbWWN4slNNlmGXTGx5qJy/rJxpKiEBvT52/CiU0 cYx0JqQcckIDvOCFKUELiGZnBGB6WMiJFQZ+k6MrI5q+irip72WaD7a/88m5oqNUH/QMIEZk+2bMf HiTdSDt0c9JH8g==; Original-Received: from [87.69.77.57] (port=3730 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 1nculB-0007CY-5y; Fri, 08 Apr 2022 15:59:09 -0400 In-Reply-To: <87lewfbsa0.fsf@ditto.jhoto.spork.org> (message from Brian Cully on Fri, 08 Apr 2022 09:42:44 -0400) 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:287980 Archived-At: > From: Brian Cully > Date: Fri, 08 Apr 2022 09:42:44 -0400 > Cc: Óscar Fuentes , emacs-devel@gnu.org > > Your proposal It isn't his proposal, it is my proposal. > crosses a line into how people should administer > their systems even when Emacs functions as expected within the context > of that system. ie, if I’m on Linux, overcommit is standard and I > presumably know how to deal with it or am ignorant of it. In either > event it is not the place of my text editor to tell me that memory > overcommit is bad. There are countless opinion pieces on the web that > will do that job just fine, should I seek them out. The proposal is to explain how overcommit affects Emacs's handling of out-of-memory situation, and how to avoid that if desired. It is up to each user to decide whether they do or don't want to do that. our users are grown-ups, or at least we should treat them as such, so they should be perfectly capable of making this decision. Whatever you think about the "usual" practice of over-committing, it basically disables a very important feature of Emacs, which is described in the user manual, so there's nothing wrong with explaining to the users why that happens and how to control this OS behavior.