From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: warn-maybe-out-of-memory Date: Fri, 11 Jul 2014 13:43:31 +0400 Message-ID: <53BFB1C3.9020202@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1405071850 12347 80.91.229.3 (11 Jul 2014 09:44:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 09:44:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 11 11:44:04 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 1X5XN4-0002zY-Vc for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 11:44:03 +0200 Original-Received: from localhost ([::1]:43530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5XN4-00048v-Jj for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 05:44:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5XMu-00048V-RE for emacs-devel@gnu.org; Fri, 11 Jul 2014 05:43:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5XMn-0004zJ-Qe for emacs-devel@gnu.org; Fri, 11 Jul 2014 05:43:52 -0400 Original-Received: from forward8l.mail.yandex.net ([84.201.143.141]:52578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5XMg-0004v6-CL; Fri, 11 Jul 2014 05:43:38 -0400 Original-Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [37.140.190.27]) by forward8l.mail.yandex.net (Yandex) with ESMTP id CE9931A421F7; Fri, 11 Jul 2014 13:43:35 +0400 (MSK) Original-Received: from smtp2o.mail.yandex.net (localhost [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id 6FF2F36A2A03; Fri, 11 Jul 2014 13:43:35 +0400 (MSK) Original-Received: from 67.gprs.mts.ru (67.gprs.mts.ru [213.87.136.67]) by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id dwbI7stsEb-hX3CvkZW; Fri, 11 Jul 2014 13:43:33 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: d9bae4ff-cfde-4a1a-898d-f013dc171639 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1405071814; bh=Qys+8lm2HEtkl6hKeATX68vmSBsz8lzrb2GaKl/Qfvs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=f4eXizd5f2zlOUCiM4MZ+3Hp4hR0yOLqr+KhKy4cub0W+r6RS9NnmYP3XzUENsjzq x/JEHO5Eb8HENYbtpYi9LywfLvqx7uc0643H2iaDZpM0M6IK8w6jbeVQe+mnMHfcW4 95uRKQq4Ek7xq9uKtfxPdu/MCwApmNJmMV6erJiw= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <8361j4b744.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.141 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:172971 Archived-At: On 07/11/2014 01:02 PM, Eli Zaretskii wrote: > I mean the cases where the file size is borderline, near the available > memory, but slightly less than that. We may warn if file size reaches or exceeds, say, 90% of available memory. > Then how does this feature make sense? It is, according to you, > unpredictable and uncontrollable. 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 and asks for 10G, the kernel may shrink page cache by 2G and satisfy 10G mmap request, thus fooling the logic I'm using to issue the warning. But under some circumstances, this may be not so; in short, I think that we need to support more OSes and gather more feedback from users. Dmitry