From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: warn-maybe-out-of-memory Date: Fri, 11 Jul 2014 09:46:15 -0400 Message-ID: References: <83egxtax97.fsf@gnu.org> <83d2ddaw52.fsf@gnu.org> <53BF6B2F.5030701@yandex.ru> <837g3kbd9g.fsf@gnu.org> <53BFA3BB.6090709@yandex.ru> <8361j4b744.fsf@gnu.org> <53BFB1C3.9020202@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1405086415 29912 80.91.229.3 (11 Jul 2014 13:46:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 13:46:55 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 11 15:46:48 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5b9y-0006Mf-Aq for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 15:46:46 +0200 Original-Received: from localhost ([::1]:44848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5b9x-0007Fu-VN for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 09:46:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5b9l-0007EU-Ps for emacs-devel@gnu.org; Fri, 11 Jul 2014 09:46:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5b9d-0006Wl-8W for emacs-devel@gnu.org; Fri, 11 Jul 2014 09:46:33 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5b9U-0006VN-DA; Fri, 11 Jul 2014 09:46:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="77168041" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Jul 2014 09:46:15 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 12769616F3; Fri, 11 Jul 2014 09:46:15 -0400 (EDT) In-Reply-To: <53BFB1C3.9020202@yandex.ru> (Dmitry Antipov's message of "Fri, 11 Jul 2014 13:43:31 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172984 Archived-At: I'm actually wondering what is the use case. Concretely. "If file looks so large that `find-file-noselect' is likely to run out of memory" is not very concrete. In what kind of situation could this happen? Especially: - in which situation is could this be useful given that we already have large-file-warning-threshold? - would using find-file-literally solve the problem? > This depends on OS and VM pressure. For example, on GNU/Linux if I have > just slightly above 8G free: > $ free > total used free shared buffers cached > Mem: 16127204 7762072 8365132 68248 84396 6401276 > -/+ buffers/cache: 1276400 14850804 Here's another problem: what kind of "free memory" do you measure? The above "free" measurement should normally be *very* small. Your above sample of 8G free typically means one of two things: - The Linux kernel's heuristics failed to make good use of your memory. - You have too much memory for what you do ("you wasted your money"). So it's perfectly normal to open a file that's larger than this "free" amount, since the goal of the kernel's memory management is to keep this "free" about as low as possible (tho not quite 0, just so we can quickly respond to new memory requests). Stefan