From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
Newsgroups: gmane.emacs.devel
Subject: Re: warn-maybe-out-of-memory
Date: Wed, 16 Jul 2014 23:59:33 -0400
Message-ID: <jwvzjg8abc6.fsf-monnier+emacs@gnu.org>
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> <jwv61j4j9u9.fsf-monnier+emacs@gnu.org>
	<5kpphafqd9.fsf@fencepost.gnu.org> <53C22ED8.5050206@yandex.ru>
	<jwv61izb86o.fsf-monnier+emacs@gnu.org> <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 <eliz@gnu.org>, emacs-devel@gnu.org
To: Dmitry Antipov <dmantipov@yandex.ru>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 17 06:00:07 2014
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <monnier@iro.umontreal.ca>) 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 <monnier@iro.umontreal.ca>) 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 <monnier@iro.umontreal.ca>)
	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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/173046>

> 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