From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: master 5c532fe303: Recommend that the user turn off memory overcommit Date: Sat, 09 Apr 2022 00:17:53 -0400 Message-ID: References: <164941780605.21656.13343783431945268284@vcs2.savannah.gnu.org> <20220408113647.815ACC051D6@vcs2.savannah.gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23473"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 06:19:23 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 1nd2ZG-0005td-Vf for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 06:19:23 +0200 Original-Received: from localhost ([::1]:40614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd2ZF-0002l0-La for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 00:19:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd2Xq-000236-G7 for emacs-devel@gnu.org; Sat, 09 Apr 2022 00:17:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd2Xp-0004pJ-OZ; Sat, 09 Apr 2022 00:17:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=KVBG3l/jITropoRD/4a1eCnSxQ0udyR9izWqpiNZelk=; b=MfBrcZ6XF4ua XK9X9L3aCJvaZ38uju583xnnJvbuosYF0/L9OtEf1yryVnQwSzFfOI0JDJCH5sG+Ote4YzqupXH4r qpnsWNg4eDxyvdv3en1QwFQGWlpRJAJAxxtRLAwal975Mjf+2+2h6E9XPPZVIkwCsiXRE4dH/q+eh qiibkCttRCnxF3rw/k+9h0gbO6tJnl+T4YUsX5rkYUf82g6l+8LKzIVy8q9raVso0gqe6tu3xxs7k l04iNCXjSnjSgOUpLakdYm2vJSNdWixbQ5R/Uw61Q8qVN+ahxwX96fKeMQ1W4eIwKP70nIzmqKUWA oKs0g+ciETam1BWZTAIokw==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nd2Xp-0004yr-FK; Sat, 09 Apr 2022 00:17:53 -0400 In-Reply-To: (message from Stefan Monnier on Fri, 08 Apr 2022 08:58: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:287992 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > +@cindex memory trouble, GNU/Linux > > + On GNU/Linux systems, the system does not normally report running > > +out of memory to Emacs, and can instead randomly kill processes when > > +they run out of memory. We recommend that you turn this behavior off, > > +so that Emacs can respond correctly when it runs out of memory, by > > +becoming the super user, editing the file @code{/etc/sysctl.conf} to > > +contain the following lines, and then running the command @code{sysctl > > +-p}: > FWIW, I think this is none of Emacs's business. The idea of "Emacs's business" is not a coherent concept when we're thinking about what to say in the Emacs Manual. The right question is, is this Emacs users' business? The Emacs Manual is meant to tell Emacs users what they need to know, and if this is something important for Emacs users to know about, that is a fine place to tell them. I don't have an opinion about what is best to do about this. However, if a problem means Emacs is likely crash, and we can't fix the problem in Emacs itself, giving users advice in the manual is good to consider. I wonder if it is possible for Emacs to explicitly ask whether it is getting close to overcommitting. Even if that approach can't entirely prevent the problem of surprise death, it might make that problem happen much less frequently. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)