From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: master 5c532fe303: Recommend that the user turn off memory overcommit Date: Sat, 09 Apr 2022 15:51:33 +1000 Message-ID: <8735imlr5h.fsf@gmail.com> References: <164941780605.21656.13343783431945268284@vcs2.savannah.gnu.org> <20220408113647.815ACC051D6@vcs2.savannah.gnu.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="12228"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.12; emacs 28.1.50 Cc: luangruo@yahoo.com, Stefan Monnier , emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 08:16:39 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 1nd4Ol-00031q-I3 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 08:16:39 +0200 Original-Received: from localhost ([::1]:58532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd4Ok-0004na-Fe for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 02:16:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd4Mt-0003wi-Rm for emacs-devel@gnu.org; Sat, 09 Apr 2022 02:14:43 -0400 Original-Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]:33944) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nd4Ms-00047O-8A; Sat, 09 Apr 2022 02:14:43 -0400 Original-Received: by mail-pj1-x102c.google.com with SMTP id g12-20020a17090a640c00b001cb59d7a57cso1400954pjj.1; Fri, 08 Apr 2022 23:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=kdKTXFS3ThpIFifdxY+XO+X8WzLsSzOiRXyhHSOTw8w=; b=Bphi5saHbBWpmVuX0NBCv8Ku8r2GxzsfEBuz9eb2H18zxV0tsezALNuPCdDY2xXRUf wCaQ+AkXEGgrUv+8f/Pny7+eiLXycdAgqeTJOQacd8/knRFzCqqLCjiYZ9eZZ1tYnqa6 4QblVXnb0ZG5KUsgrz0mWMTz8IlaDuKw4ancvxLhCGAqRBxsDEhyturfbGMK3xXJ5Uyo 9v7TbDmKke2fkvbJHXsFN5b4XoN566l2HOQgFgVblcp6S0QxDvi+uA7Cs9Eelei/nx0h qBkj/P3tIU/SxIYhBHwBwfaBr3MPZdEMpHWZtgidJ52GLmkYHMVSjKEaVqmARBZIR9fM aFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=kdKTXFS3ThpIFifdxY+XO+X8WzLsSzOiRXyhHSOTw8w=; b=WMibhhDYbeWCejqEzvoz9XvGmXWzanN2OSzC77kop07apAzXCDjjNy+Jlw4alahXOY TrNL2G3mT8u5mLR4F2LKWNiQelsQyfz24FetG43/kHKNO03vMpSZTmgMWKTBmWoNtLEy JS6DaVxx6rxySWAzVd7fiMcHTkcozTiooETC0GsfTkYG0JYHHIcVMS30eczOCU9dibAm hDTApjLTCb5+lIppO30GFAxHapXaM1PQqjP8i4k1mWsKHzb2XFdp/n5qoyfqqezrnWF6 GLLm1tvzwEKKCzSmfIWBvwjWkgJpwzO/ldGIELZtu0araiGH3TOlxfpYXhedGv/8NcsJ uP2Q== X-Gm-Message-State: AOAM530fezs8VEDfT3oJ8zmTwT9Sayj58/omP9Nr0qf3YXSEEWr6AXiY Ro4HpV9C+paURAxDfsQYFWxw7A8Usvo= X-Google-Smtp-Source: ABdhPJygBnorHiSiFhoKO6qnXUYug+Uo6Nrip2UJVULcco4ZnbuL3LpKtgmaKPHvAR/Umd+Fc0SmhA== X-Received: by 2002:a17:902:8343:b0:156:8e48:19b8 with SMTP id z3-20020a170902834300b001568e4819b8mr23208270pln.63.1649484879996; Fri, 08 Apr 2022 23:14:39 -0700 (PDT) Original-Received: from dingbat (220-235-26-154.dyn.iinet.net.au. [220.235.26.154]) by smtp.gmail.com with ESMTPSA id e4-20020a656884000000b0039d087188d7sm2861629pgt.19.2022.04.08.23.14.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 23:14:39 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:287996 Archived-At: Richard Stallman writes: > [[[ 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. I suspect the problem may be the 'we recommend". I'm not sure "we" should be recommending modifying default system settings just for the benefit of one application. Isn't the whole purpose of random killing processes to free up resources and prevent core services from failing and crashing the system? If this is the case, recommending turning it off to allow Emacs to gracefully handle out of memory situations might not be of any benefit given it will be more likely for the system to crash in these situations, preventing any action by Emacs. Might be better to just state what the situation is and one possible option to consider if it becomes a frequent issue (i.e. Emacs being killed unexpectedly). Is this a very common issue? I've run Emacs on some pretty old systems with little memory and while I've certainly had processes killed, it has never killed Emacs.