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: Wed, 16 Jul 2014 23:59:33 -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> <5kpphafqd9.fsf@fencepost.gnu.org> <53C22ED8.5050206@yandex.ru> <53C4B1AB.8010402@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1405569614 6128 80.91.229.3 (17 Jul 2014 04:00:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Jul 2014 04:00:14 +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 Thu Jul 17 06:00:07 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 1X7crV-0005HN-1v for ged-emacs-devel@m.gmane.org; Thu, 17 Jul 2014 06:00:05 +0200 Original-Received: from localhost ([::1]:42184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7crU-0007RH-Mp for ged-emacs-devel@m.gmane.org; Thu, 17 Jul 2014 00:00:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7crK-0007Qp-Mx for emacs-devel@gnu.org; Thu, 17 Jul 2014 00:00:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X7crD-0002eF-6O for emacs-devel@gnu.org; Wed, 16 Jul 2014 23:59:54 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7cr5-0002dl-95; Wed, 16 Jul 2014 23:59:39 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s6H3xaC9008308; Wed, 16 Jul 2014 23:59:36 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B5B8BAE093; Wed, 16 Jul 2014 23:59:33 -0400 (EDT) In-Reply-To: <53C4B1AB.8010402@yandex.ru> (Dmitry Antipov's message of "Tue, 15 Jul 2014 08:44:27 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5005=0 X-NAI-Spam-Version: 2.3.0.9378 : core <5005> : inlines <1083> : streams <1240504> : uri <1792113> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:173046 Archived-At: > AFAICS on Linux, this is not true - in my tests, huge allocations > may be 20% slower when the kernel should reclaim cache space first. 20% slower is still pretty damn fast compared to the time Emacs will take to fill that space, so it's really not a reason to take this measurement into account. >> The OS wants to keep as much stuff in the cache as it can, thus >> minimizing the "free" space, since "free" here basically means "wasted". > This depends on usage patterns. If you interleave I/O and relatively > large allocations, it's fairly unreasonable to fill almost all memory > with cached data just to throw it away very soon. No, the OS doesn't actively fill the memory with cache data. It just waits to throw it away as late as possible. >> If your "free" includes "free in RAM + free in swap" then it's >> marginally more useful ("free in RAM" will usually be close to 0, >> whereas "free in swap" should usually be fairly large), but I still >> can't think of a frequent enough configuration and situation where this >> would be useful enough to justify wasting code on it. > This is not expected to be frequent. I'm not just talking about "infrequent". Currently, I can't think of a single case where this would be useful given the existence of large-file-threshold. Stefan