From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Sun, 11 Dec 2011 17:49:23 +0000 Message-ID: <87ehwb80d8.fsf@spindle.srvr.nix> References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <87borlu0kc.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323625782 30862 80.91.229.12 (11 Dec 2011 17:49:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2011 17:49:42 +0000 (UTC) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 18:49:38 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RZnWr-0007mU-9F for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2011 18:49:37 +0100 Original-Received: from localhost ([::1]:34260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZnWq-0006q7-Tw for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2011 12:49:36 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZnWn-0006pq-MP for emacs-devel@gnu.org; Sun, 11 Dec 2011 12:49:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZnWm-0003Px-Nd for emacs-devel@gnu.org; Sun, 11 Dec 2011 12:49:33 -0500 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:37098 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZnWm-0003Ok-99 for emacs-devel@gnu.org; Sun, 11 Dec 2011 12:49:32 -0500 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id pBBHnNji022342; Sun, 11 Dec 2011 17:49:23 GMT Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id pBBHnNt9021743; Sun, 11 Dec 2011 17:49:23 GMT Emacs: if SIGINT doesn't work, try a tranquilizer. In-Reply-To: (Stefan Monnier's message of "Tue, 06 Dec 2011 14:53:46 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=3 Fuz1=3 Fuz2=3 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 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:146651 Archived-At: On 6 Dec 2011, Stefan Monnier stated: >> I'm writing this message on that very same emacs process. Right now it >> has 60 buffers, all of them with a size below 50KB and most below >> 10KB. As reported by `htop', the process is using 533MB of RES memory >> and 630MB of VIRT memory. > > Nothing of what you say sounds worrisome: apparently you now have around > half a GB of memory allocated for use by Lisp data. Most likely the > majority of it is considered by Emacs as "free for reuse", but it's not > returned to the OS because that is only done in "big chunks" (typically > 10KB or so) and none of the big chunks are 100% free (they all contain > at least one non-free object). More generally, unless this is the *last* such chunk allocated, it's not going to be returned to the OS (as 10Kb regions are small enough that they're going to come from brk space on every malloc I've ever heard of, not malloc space). It might be worth trying to boost that 10Kb 'big' chunk to 2Mb or something. That'll force mmap() allocation on a lot of recent Linux systems. (Of course, if you have tens of thousands of those, you can run into kernel limits: but if your Emacs is using that much memory, you have bigger problems.) -- NULL && (void)