Greetings! The BTS seems to have swallowed my reply of yesterday to you. In any case, my results seem to show that the total build avoids swap, and that Committed_AS is misleading relative to other variables in /proc/meminfo for this purpose.
Does this close the issue for you? (P.S. if you have the text of my results and can post it to the BTS in a way that takes, that would be great.) Take care, Santiago Vila <sanv...@unex.es> writes: > Package: maxima > Version: 5.38.0-3 > > Hello Camm. > > The more memory it has the machine on which I build this package, > the more memory it uses during the build, and there does not seem to > be a limit for that. > > Last time it was a machine with 8GB RAM. The file /proc/meminfo > reported a Committed_AS memory of 17823MB (more than 17GB!). > > This is specially bad for me because I rely on /proc/meminfo to know > how much memory the package "really" needs. > > While checking for "dpkg-buildpackage -A" I have measured the memory > required to build around 3400 different source packages in stretch. > If I order them by required memory, these are the last 20: > > [...] > gnutls28 4189 > mapnik 4199 > mia 4279 > gcc-4.9 4287 > gap-guava 4315 > seqan 4376 > yade 4509 > webkit2gtk 4558 > llvm-toolchain-3.8 4673 > aces3 4795 > python2.7 5685 > libbson 5700 > webkitgtk 7015 > acl2 7355 > gap 8268 > gcl 9375 > mame 10363 > gdk-pixbuf 11564 > maxima 17823 > axiom 21190 > > In practice, this means several things: > > * As I don't currently have such a big machine, I have to rent one to > build those packages. > > * As they use so much memory, I can't use a 8GB plan or a 12GB plan, I > have to use a 24GB plan (or whatever is close). > > * I need a bigger machine *only* to build the packages at the end of > the above list. > > I know that you have been fine-tuning the memory usage for these > programs lately, but it still happens that the more memory II have, > the more memory they take, so I still have the problem that I can't > measure how much memory they really need. > > Thanks. > From unknown Mon Sep 26 19:22:45 2016 > X-Loop: ow...@bugs.debian.org > Subject: Bug#827953: maxima: Uses too much memory to build > Reply-To: Camm Maguire <c...@maguirefamily.org>, 827...@bugs.debian.org > Resent-From: Camm Maguire <c...@maguirefamily.org> > Resent-To: debian-bugs-dist@lists.debian.org > Resent-CC: Camm Maguire <c...@debian.org> > X-Loop: ow...@bugs.debian.org > Resent-Date: Sun, 10 Jul 2016 15:39:06 +0000 > Resent-Message-ID: <handler.827953.b827953.146816505024...@bugs.debian.org> > Resent-Sender: ow...@bugs.debian.org > X-Debian-PR-Message: followup 827953 > X-Debian-PR-Package: maxima > X-Debian-PR-Keywords: > X-Debian-PR-Source: maxima > Received: via spool by 827953-sub...@bugs.debian.org > id=B827953.146816505024139 > (code B ref 827953); Sun, 10 Jul 2016 15:39:06 +0000 > Received: (at 827953) by bugs.debian.org; 10 Jul 2016 15:37:30 +0000 > X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 > (2014-02-07) on buxtehude.debian.org > X-Spam-Level: > X-Spam-Status: No, score=-4.4 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, > HDRS_LCASE,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, > RCVD_IN_MSPIKE_WL,T_MANY_HDRS_LCASE,URIBL_CNKR autolearn=ham > autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02 > X-Spam-Bayes: score:0.0000 Tokens: new, 10; hammy, 150; neutral, 132; spammy, > 0. spammytokens: hammytokens:0.000-+--python27, 0.000-+--python2.7, > 0.000-+--H*f:sk:alpine., 0.000-+--H*u:Gnus, 0.000-+--H*u:linux > Received: from vms173017pub.verizon.net ([206.46.173.17]) > by buxtehude.debian.org with esmtps > (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) > (Exim 4.84_2) > (envelope-from <c...@maguirefamily.org>) > id 1bMGnS-0006H2-3e > for 827...@bugs.debian.org; Sun, 10 Jul 2016 15:37:30 +0000 > Received: from vz-proxy-m001.mx.aol.com ([64.236.83.14]) > by vms173017.mailsrvcs.net > (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) > with ESMTPA id <0oa300dg7slhk...@vms173017.mailsrvcs.net> for > 827...@bugs.debian.org; Sun, 10 Jul 2016 09:36:59 -0500 (CDT) > X-CMAE-Score: 0 > X-CMAE-Analysis: v=2.1 cv=J+9Xl1TS c=1 sm=1 tr=0 > a=MJxOpqxZADbEbEImuSX/mw==:117 > a=kj9zAlcOel0A:10 a=cAmyUtKerLwA:10 a=9N09Ue-cAAAA:8 > a=ZeoOlCyH8KQX3YoRE1wA:9 > a=CjuIK1q_8ugA:10 > Received: by 173.61.133.218 with SMTP id 18f50746; Sun, 10 Jul 2016 14:36:59 > GMT > Received: from camm by localhost.m.enhanced.com with local (Exim 4.80) > (envelope-from <c...@maguirefamily.org>) id 1bMFqR-0006PD-Im; > Sun, > 10 Jul 2016 10:36:31 -0400 > From: Camm Maguire <c...@maguirefamily.org> > To: Santiago Vila <sanv...@unex.es> > Cc: 827...@bugs.debian.org > References: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > Date: Sun, 10 Jul 2016 10:36:31 -0400 > In-reply-to: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > (Santiago Vila's message of "Thu, 23 Jun 2016 11:48:46 +0200 (CEST)") > Message-id: <874m7x36hc....@maguirefamily.org> > User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > X-Greylist: delayed 3605 seconds by postgrey-1.35 at buxtehude; Sun, 10 Jul > 2016 15:37:29 UTC > > Greetings, and thanks so much for your report! More reply later, but > just want to point out for now that the memory used for the build > depends on the memory available at runtime. These packages will build > just fine on machines with small memories. The memory usage algorithm > is a performance booster only. > > Take care, > > Santiago Vila <sanv...@unex.es> writes: > >> Package: maxima >> Version: 5.38.0-3 >> >> Hello Camm. >> >> The more memory it has the machine on which I build this package, >> the more memory it uses during the build, and there does not seem to >> be a limit for that. >> >> Last time it was a machine with 8GB RAM. The file /proc/meminfo >> reported a Committed_AS memory of 17823MB (more than 17GB!). >> >> This is specially bad for me because I rely on /proc/meminfo to know >> how much memory the package "really" needs. >> >> While checking for "dpkg-buildpackage -A" I have measured the memory >> required to build around 3400 different source packages in stretch. >> If I order them by required memory, these are the last 20: >> >> [...] >> gnutls28 4189 >> mapnik 4199 >> mia 4279 >> gcc-4.9 4287 >> gap-guava 4315 >> seqan 4376 >> yade 4509 >> webkit2gtk 4558 >> llvm-toolchain-3.8 4673 >> aces3 4795 >> python2.7 5685 >> libbson 5700 >> webkitgtk 7015 >> acl2 7355 >> gap 8268 >> gcl 9375 >> mame 10363 >> gdk-pixbuf 11564 >> maxima 17823 >> axiom 21190 >> >> In practice, this means several things: >> >> * As I don't currently have such a big machine, I have to rent one to >> build those packages. >> >> * As they use so much memory, I can't use a 8GB plan or a 12GB plan, I >> have to use a 24GB plan (or whatever is close). >> >> * I need a bigger machine *only* to build the packages at the end of >> the above list. >> >> I know that you have been fine-tuning the memory usage for these >> programs lately, but it still happens that the more memory II have, >> the more memory they take, so I still have the problem that I can't >> measure how much memory they really need. >> >> Thanks. >> >> >> >> > > -- > Camm Maguire c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > From unknown Mon Sep 26 19:22:45 2016 > X-Loop: ow...@bugs.debian.org > Subject: Bug#827953: maxima: Uses too much memory to build > Reply-To: Santiago Vila <sanv...@unex.es>, 827...@bugs.debian.org > Resent-From: Santiago Vila <sanv...@unex.es> > Resent-To: debian-bugs-dist@lists.debian.org > Resent-CC: Camm Maguire <c...@debian.org> > X-Loop: ow...@bugs.debian.org > Resent-Date: Mon, 25 Jul 2016 09:21:02 +0000 > Resent-Message-ID: <handler.827953.b827953.14694381974...@bugs.debian.org> > Resent-Sender: ow...@bugs.debian.org > X-Debian-PR-Message: followup 827953 > X-Debian-PR-Package: maxima > X-Debian-PR-Keywords: > X-Debian-PR-Source: maxima > Received: via spool by 827953-sub...@bugs.debian.org id=B827953.14694381974894 > (code B ref 827953); Mon, 25 Jul 2016 09:21:02 +0000 > Received: (at 827953) by bugs.debian.org; 25 Jul 2016 09:16:37 +0000 > X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 > (2014-02-07) on buxtehude.debian.org > X-Spam-Level: > X-Spam-Status: No, score=-8.2 required=4.0 tests=BAYES_00,FOURLA, > HAS_BUG_NUMBER,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, > RP_MATCHES_RCVD,SPF_PASS autolearn=ham autolearn_force=no > version=3.4.0-bugs.debian.org_2005_01_02 > X-Spam-Bayes: score:0.0000 Tokens: new, 29; hammy, 121; neutral, 60; spammy, > 1. spammytokens:0.854-1--booster hammytokens:0.000-+--H*f:sk:alpine., > 0.000-+--H*F:U*sanvila, 0.000-+--H*rp:U*sanvila, > 0.000-+--H*MI:sk:alpine., > 0.000-+--H*RU:sanv...@unex.es > Received: from zmta01.unex.es ([158.49.17.55]) > by buxtehude.debian.org with esmtps > (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) > (Exim 4.84_2) > (envelope-from <sanv...@unex.es>) > id 1bRc05-0001Ga-6d > for 827...@bugs.debian.org; Mon, 25 Jul 2016 09:16:37 +0000 > Received: from localhost (localhost [127.0.0.1]) > by zmta01.unex.es (Postfix) with ESMTP id 51A10600B8; > Mon, 25 Jul 2016 11:16:32 +0200 (CEST) > Received: from zmta01.unex.es ([127.0.0.1]) > by localhost (zmta01.servicios.unex.es [127.0.0.1]) (amavisd-new, port > 10032) > with ESMTP id 4EZG5ZfYcF9P; Mon, 25 Jul 2016 11:16:27 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zmta01.unex.es (Postfix) with ESMTP id 1C0EC600BF; > Mon, 25 Jul 2016 11:16:27 +0200 (CEST) > X-Virus-Scanned: amavisd-new at zmta01.siue > Received: from zmta01.unex.es ([127.0.0.1]) > by localhost (zmta01.servicios.unex.es [127.0.0.1]) (amavisd-new, port > 10026) > with ESMTP id luFmsEKe4riq; Mon, 25 Jul 2016 11:16:26 +0200 (CEST) > Received: from zproxy01.unex.es (zproxy01.servicios.unex.es [10.254.208.61]) > by zmta01.unex.es (Postfix) with ESMTPS id E05F3600BE; > Mon, 25 Jul 2016 11:16:26 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zproxy01.unex.es (Postfix) with ESMTP id D73A0801FE; > Mon, 25 Jul 2016 11:16:26 +0200 (CEST) > Received: from zproxy01.unex.es ([127.0.0.1]) > by localhost (zproxy01.servicios.unex.es [127.0.0.1]) (amavisd-new, > port 10032) > with ESMTP id spdV8XXSdOSB; Mon, 25 Jul 2016 11:16:21 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zproxy01.unex.es (Postfix) with ESMTP id 43E39801FF; > Mon, 25 Jul 2016 11:16:21 +0200 (CEST) > X-Virus-Scanned: amavisd-new at zproxy01.siue > Received: from zproxy01.unex.es ([127.0.0.1]) > by localhost (zproxy01.servicios.unex.es [127.0.0.1]) (amavisd-new, > port 10026) > with ESMTP id 2Dy7qam5ahgU; Mon, 25 Jul 2016 11:16:20 +0200 (CEST) > Received: from tulipan.isla-invisible.es (tulipan.isla-invisible.es > [185.92.222.134]) > by zproxy01.unex.es (Postfix) with ESMTPSA id C88BC80212; > Mon, 25 Jul 2016 11:16:20 +0200 (CEST) > Received: by tulipan.isla-invisible.es (Postfix, from userid 1000) > id 9A5DB84E; Mon, 25 Jul 2016 11:16:19 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by tulipan.isla-invisible.es (Postfix) with ESMTP id 86927658; > Mon, 25 Jul 2016 11:16:19 +0200 (CEST) > Date: Mon, 25 Jul 2016 11:16:19 +0200 (CEST) > From: Santiago Vila <sanv...@unex.es> > To: Camm Maguire <c...@maguirefamily.org> > cc: 827...@bugs.debian.org > In-Reply-To: <874m7x36hc....@maguirefamily.org> > Message-ID: <alpine.deb.2.11.1607251101430.3...@tulipan.isla-invisible.es> > References: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > <874m7x36hc....@maguirefamily.org> > User-Agent: Alpine 2.11 (DEB 23 2013-08-11) > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Sun, 10 Jul 2016, Camm Maguire wrote: > >> Greetings, and thanks so much for your report! More reply later, but >> just want to point out for now that the memory used for the build >> depends on the memory available at runtime. These packages will build >> just fine on machines with small memories. The memory usage algorithm >> is a performance booster only. > > Hello Camm. > > There are at least two problems with the current approach: > > * One of them (which I already pointed out) is that I can't measure how > much this program really needs by looking at memory usage. I can do > that for more than 3300 different packages in stretch, but I can't for > maxima and axiom, which is a pity. > > * The other problem is that not only maxima takes as much RAM as I > have, it seems to use all available SWAP as well! This would explain > the effect "the more memory I have, the more memory it takes". Let's > suppose that I build with 4 GB RAM and 4 GB SWAP. Then I measure > that maxima takes 8GB and next time I will need 8 GB RAM to build. > > If maxima is going to take all the memory I have, whatever the amount, > it should be the available RAM only, not available RAM + available SWAP. > > If it's not able to do that and it only takes the total memory in > account, meybe it should assume that at least half of that is SWAP and > avoid using it. > > Currently, it seems to assume that all the memory is available to use, > which is not realistic for people using SWAP as a safety net. > > Thanks. > From unknown Mon Sep 26 19:22:45 2016 > X-Loop: ow...@bugs.debian.org > Subject: Bug#827953: maxima: Uses too much memory to build > Reply-To: Camm Maguire <c...@maguirefamily.org>, 827...@bugs.debian.org > Resent-From: Camm Maguire <c...@maguirefamily.org> > Resent-To: debian-bugs-dist@lists.debian.org > Resent-CC: Camm Maguire <c...@debian.org> > X-Loop: ow...@bugs.debian.org > Resent-Date: Mon, 25 Jul 2016 14:54:13 +0000 > Resent-Message-ID: <handler.827953.b827953.14694583657...@bugs.debian.org> > Resent-Sender: ow...@bugs.debian.org > X-Debian-PR-Message: followup 827953 > X-Debian-PR-Package: maxima > X-Debian-PR-Keywords: > X-Debian-PR-Source: maxima > Received: via spool by 827953-sub...@bugs.debian.org id=B827953.14694583657999 > (code B ref 827953); Mon, 25 Jul 2016 14:54:13 +0000 > Received: (at 827953) by bugs.debian.org; 25 Jul 2016 14:52:45 +0000 > X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 > (2014-02-07) on buxtehude.debian.org > X-Spam-Level: > X-Spam-Status: No, score=-4.3 required=4.0 tests=BAYES_00,FOURLA, > HAS_BUG_NUMBER,HDRS_LCASE,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_LOW, > RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_MANY_HDRS_LCASE,URIBL_CNKR > autolearn=ham autolearn_force=no > version=3.4.0-bugs.debian.org_2005_01_02 > X-Spam-Bayes: score:0.0000 Tokens: new, 13; hammy, 147; neutral, 100; spammy, > 3. spammytokens:0.998-1--measurer, 0.969-+--HContent-type:charset, > 0.966-+--HContent-type:text hammytokens:0.000-+--H*f:sk:alpine., > 0.000-+--H*u:Gnus, 0.000-+--H*u:linux, 0.000-+--H*UA:linux, > 0.000-+--H*u:gnu > Received: from vms173009pub.verizon.net ([206.46.173.9]) > by buxtehude.debian.org with esmtps > (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) > (Exim 4.84_2) > (envelope-from <c...@maguirefamily.org>) > id 1bRhFM-00024i-Uy > for 827...@bugs.debian.org; Mon, 25 Jul 2016 14:52:45 +0000 > Received: from vz-proxy-m001.mx.aol.com ([64.236.83.14]) > by vms173009.mailsrvcs.net > (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) > with ESMTPA id <0oav00joblbaj...@vms173009.mailsrvcs.net> for > 827...@bugs.debian.org; Mon, 25 Jul 2016 09:52:38 -0500 (CDT) > X-CMAE-Score: 0 > X-CMAE-Analysis: v=2.1 cv=EdU1O6SC c=1 sm=1 tr=0 > a=MJxOpqxZADbEbEImuSX/mw==:117 > a=kj9zAlcOel0A:10 a=cAmyUtKerLwA:10 a=9N09Ue-cAAAA:8 > a=bHqQWnbuvog34Ccv-BkA:9 > a=CjuIK1q_8ugA:10 > Received: by 173.61.133.218 with SMTP id 664ec1d9; Mon, 25 Jul 2016 14:52:36 > GMT > Received: from camm by localhost.m.enhanced.com with local (Exim 4.80) > (envelope-from <c...@maguirefamily.org>) id 1bRhEa-0007Dv-HK; > Mon, > 25 Jul 2016 10:51:56 -0400 > From: Camm Maguire <c...@maguirefamily.org> > To: Santiago Vila <sanv...@unex.es> > Cc: 827...@bugs.debian.org > References: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > <874m7x36hc....@maguirefamily.org> > <alpine.deb.2.11.1607251101430.3...@tulipan.isla-invisible.es> > Date: Mon, 25 Jul 2016 10:51:56 -0400 > In-reply-to: <alpine.deb.2.11.1607251101430.3...@tulipan.isla-invisible.es> > (Santiago Vila's message of "Mon, 25 Jul 2016 11:16:19 +0200 (CEST)") > Message-id: <87h9bdpy7n....@maguirefamily.org> > User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > > Greetings, and thanks for your report! > > Santiago Vila <sanv...@unex.es> writes: > >> On Sun, 10 Jul 2016, Camm Maguire wrote: >> >>> Greetings, and thanks so much for your report! More reply later, but >>> just want to point out for now that the memory used for the build >>> depends on the memory available at runtime. These packages will build >>> just fine on machines with small memories. The memory usage algorithm >>> is a performance booster only. >> >> Hello Camm. >> >> There are at least two problems with the current approach: >> >> * One of them (which I already pointed out) is that I can't measure how >> much this program really needs by looking at memory usage. I can do >> that for more than 3300 different packages in stretch, but I can't for >> maxima and axiom, which is a pity. > > OK, this might be an inconvenience from an 'package builder memory > measurer' but is not a critical issue, right? > >> >> * The other problem is that not only maxima takes as much RAM as I >> have, it seems to use all available SWAP as well! This would explain >> the effect "the more memory I have, the more memory it takes". Let's >> suppose that I build with 4 GB RAM and 4 GB SWAP. Then I measure >> that maxima takes 8GB and next time I will need 8 GB RAM to build. >> > > If this is happening, then it is indeed a bug. The intent is to use > physical ram only by default unless the application itself insists on > more. Going into swap by default obviously defeats the performance goal > of expanding the memory anyway. You can look into this by > > gcl >>(room t) > > and > > maxima > (..) :lisp (room t) > (..) :lisp (setq si::*notify-gbc* t) > (..) run_testsuite(); > (..) :lisp (room t) > > If you can post the results for this on the 4/4 machine you describe > above I can see if we have a problem. > > The available memory should be 8G, garbage collection should start at > 2G, become very heavy by 0.9*4G, beyond which the system should not > expand unless the memory cannot be reclaimed by garbage collection. > > Take care, > -- > Camm Maguire c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > From unknown Mon Sep 26 19:22:45 2016 > X-Loop: ow...@bugs.debian.org > Subject: Bug#827953: maxima: Uses too much memory to build > Reply-To: Santiago Vila <sanv...@unex.es>, 827...@bugs.debian.org > Resent-From: Santiago Vila <sanv...@unex.es> > Resent-To: debian-bugs-dist@lists.debian.org > Resent-CC: Camm Maguire <c...@debian.org> > X-Loop: ow...@bugs.debian.org > Resent-Date: Sun, 28 Aug 2016 23:09:11 +0000 > Resent-Message-ID: <handler.827953.b827953.147242557821...@bugs.debian.org> > Resent-Sender: ow...@bugs.debian.org > X-Debian-PR-Message: followup 827953 > X-Debian-PR-Package: maxima > X-Debian-PR-Keywords: > X-Debian-PR-Source: maxima > Received: via spool by 827953-sub...@bugs.debian.org > id=B827953.147242557821401 > (code B ref 827953); Sun, 28 Aug 2016 23:09:11 +0000 > Received: (at 827953) by bugs.debian.org; 28 Aug 2016 23:06:18 +0000 > X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 > (2014-02-07) on buxtehude.debian.org > X-Spam-Level: > X-Spam-Status: No, score=-6.2 required=4.0 tests=BAYES_00,DIGITS_LETTERS, > > FOURLA,HAS_BUG_NUMBER,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, > RP_MATCHES_RCVD,SPF_PASS autolearn=ham autolearn_force=no > version=3.4.0-bugs.debian.org_2005_01_02 > X-Spam-Bayes: score:0.0000 Tokens: new, 73; hammy, 149; neutral, 355; spammy, > 1. spammytokens:0.997-1--afun hammytokens:0.000-+--H*f:sk:alpine., > 0.000-+--H*F:U*sanvila, 0.000-+--H*rp:U*sanvila, > 0.000-+--H*MI:sk:alpine., > 0.000-+--H*RU:sanv...@unex.es > Received: from zmta02.unex.es ([158.49.17.56]) > by buxtehude.debian.org with esmtps > (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) > (Exim 4.84_2) > (envelope-from <sanv...@unex.es>) > id 1be99e-0005Ym-9W > for 827...@bugs.debian.org; Sun, 28 Aug 2016 23:06:18 +0000 > Received: from localhost (localhost [127.0.0.1]) > by zmta02.unex.es (Postfix) with ESMTP id EC72C60EE8; > Mon, 29 Aug 2016 01:06:13 +0200 (CEST) > Received: from zmta02.unex.es ([127.0.0.1]) > by localhost (zmta02.servicios.unex.es [127.0.0.1]) (amavisd-new, port > 10032) > with ESMTP id 7bmDiL5_Gg04; Mon, 29 Aug 2016 01:06:07 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zmta02.unex.es (Postfix) with ESMTP id A5D7D60F9A; > Mon, 29 Aug 2016 01:06:07 +0200 (CEST) > X-Virus-Scanned: amavisd-new at zmta02.siue > Received: from zmta02.unex.es ([127.0.0.1]) > by localhost (zmta02.servicios.unex.es [127.0.0.1]) (amavisd-new, port > 10026) > with ESMTP id A7JzemtP4AMt; Mon, 29 Aug 2016 01:06:06 +0200 (CEST) > Received: from zproxy02.unex.es (zproxy02.servicios.unex.es [10.254.208.62]) > by zmta02.unex.es (Postfix) with ESMTPS id 1C9A360EE8; > Mon, 29 Aug 2016 01:06:06 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zproxy02.unex.es (Postfix) with ESMTP id 0C6D460F3F; > Mon, 29 Aug 2016 01:06:06 +0200 (CEST) > Received: from zproxy02.unex.es ([127.0.0.1]) > by localhost (zproxy02.servicios.unex.es [127.0.0.1]) (amavisd-new, > port 10032) > with ESMTP id Z2Q4gYC8wZpm; Mon, 29 Aug 2016 01:05:59 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by zproxy02.unex.es (Postfix) with ESMTP id C3A4D60F57; > Mon, 29 Aug 2016 01:05:59 +0200 (CEST) > X-Virus-Scanned: amavisd-new at zproxy02.siue > Received: from zproxy02.unex.es ([127.0.0.1]) > by localhost (zproxy02.servicios.unex.es [127.0.0.1]) (amavisd-new, > port 10026) > with ESMTP id JAYi31UGXjHZ; Mon, 29 Aug 2016 01:05:59 +0200 (CEST) > Received: from tulipan.isla-invisible.es (tulipan.isla-invisible.es > [185.92.222.134]) > by zproxy02.unex.es (Postfix) with ESMTPSA id 719D960F3F; > Mon, 29 Aug 2016 01:05:59 +0200 (CEST) > Received: by tulipan.isla-invisible.es (Postfix, from userid 1000) > id 44A0213D8; Mon, 29 Aug 2016 01:05:57 +0200 (CEST) > Received: from localhost (localhost [127.0.0.1]) > by tulipan.isla-invisible.es (Postfix) with ESMTP id 39A8DA2D; > Mon, 29 Aug 2016 01:05:57 +0200 (CEST) > Date: Mon, 29 Aug 2016 01:05:55 +0200 (CEST) > From: Santiago Vila <sanv...@unex.es> > To: Camm Maguire <c...@maguirefamily.org> > cc: 827...@bugs.debian.org > In-Reply-To: <87h9bdpy7n....@maguirefamily.org> > Message-ID: <alpine.deb.2.11.1608290058270.7...@tulipan.isla-invisible.es> > References: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > <874m7x36hc....@maguirefamily.org> > <alpine.deb.2.11.1607251101430.3...@tulipan.isla-invisible.es> > <87h9bdpy7n....@maguirefamily.org> > User-Agent: Alpine 2.11 (DEB 23 2013-08-11) > MIME-Version: 1.0 > Content-Type: MULTIPART/MIXED; > BOUNDARY="1555662558-153843084-1472425557=:7248" > > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --1555662558-153843084-1472425557=:7248 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Mon, 25 Jul 2016, Camm Maguire wrote: > >> If this is happening, then it is indeed a bug. The intent is to use >> physical ram only by default unless the application itself insists on >> more. Going into swap by default obviously defeats the performance goal >> of expanding the memory anyway. You can look into this by >> >> gcl >> >(room t) >> >> and >> >> maxima >> (..) :lisp (room t) >> (..) :lisp (setq si::*notify-gbc* t) >> (..) run_testsuite(); >> (..) :lisp (room t) >> >> If you can post the results for this on the 4/4 machine you describe >> above I can see if we have a problem. > > Sorry for the late reply. > > I attach the results for maxima, on a machine with 6GB RAM and 4GB swap. > > I don't know how to interpret the results. In addition to the test you > requested, when I do this > > grep "Committed_AS:" /proc/meminfo > > I get this before running maxima: > > Committed_AS: 254276 kB > > and this after the test finished, before exiting maxima: > > Committed_AS: 6878284 kB > > I guess this does still not explain why Committed_AS: grows so much > when I'm actually trying to build the Debian package. > > Thanks. > --1555662558-153843084-1472425557=:7248 > Content-Type: TEXT/plain; name=typescript.txt > Content-Transfer-Encoding: BASE64 > Content-ID: <alpine.deb.2.11.1608290105550.7...@tulipan.isla-invisible.es> > Content-Description: > Content-Disposition: attachment; filename=typescript.txt > > KHNpZClidWlsZGRAc2t5d2Fsa2VyMTp+JCBtYXhpbWENCg0KTWF4aW1hIDUu > MzguMCBodHRwOi8vbWF4aW1hLnNvdXJjZWZvcmdlLm5ldA0KdXNpbmcgTGlz > cCBHTlUgQ29tbW9uIExpc3AgKEdDTCkgR0NMIDIuNi4xMg0KRGlzdHJpYnV0 > ZWQgdW5kZXIgdGhlIEdOVSBQdWJsaWMgTGljZW5zZS4gU2VlIHRoZSBmaWxl > IENPUFlJTkcuDQpEZWRpY2F0ZWQgdG8gdGhlIG1lbW9yeSBvZiBXaWxsaWFt > IFNjaGVsdGVyLg0KVGhlIGZ1bmN0aW9uIGJ1Z19yZXBvcnQoKSBwcm92aWRl > cyBidWcgcmVwb3J0aW5nIGluZm9ybWF0aW9uLg0KKCVpMSkgDSglaTEpIDps > aXNwIChyb29tIHQpDQoNDQogICAgMTgyOC8xODI4ICAgICAgICA4OC44JSAg > ICAgICAgIENPTlMgRklYTlVNIFNIT1JULUZMT0FUIExPTkctRkxPQVQgQklU > LVZFQ1RPUiBQQVRITkFNRSBTUElDRQ0KICAgICAyMjAvMjIwICAgICAgICAg > OTkuOCUgICAgICAgICBBUlJBWSBDSEFSQUNURVIgUEFDS0FHRSBIQVNILVRB > QkxFIFZFQ1RPUiBSQU5ET00tU1RBVEUgQ0NMT1NVUkUgQ0xPU1VSRQ0KICAg > ICAgNjcvNjcgICAgICAgICAgNTYuNyUgICAgICAgICBTVFJJTkcgQklHTlVN > IFJBVElPIENPTVBMRVgNCiAgICAgMzk5LzM5OSAgICAgICAgIDk4LjglICAg > ICAgICAgU1RSVUNUVVJFDQogICAgICAgMS8xICAgICAgICAgICA2NS4yJSAg > ICAgICAgIFNUUkVBTQ0KICAgICAgNDYvNDYgICAgICAgICAgOTkuNCUgICAg > ICAgICBDRlVOIENGREFUQQ0KICAgICA1OTIvNTkyICAgICAgICAgOTkuOCUg > ICAgICAgICBTRlVOIFNZTUJPTCBSRUFEVEFCTEUgR0ZVTiBWRlVOIEFGVU4N > Cg0KICAgIDY0MDAvNjQwMCAgICAgICAgICAgICAgICAgICAgICBjb250aWd1 > b3VzICgzMCBibG9ja3MpDQogICAgICAgICAxMTczMzM3ICAgICAgICAgICAg > ICAgICAgIGhvbGUNCiAgICAgMjE2LzIxNiAgICAgICAgIDk5LjklICAgICAg > ICAgcmVsb2NhdGFibGUNCg0KICAgICAgMzE1MyBwYWdlcyBmb3IgY2VsbHMN > Cg0KICAgICAgOTc2OSB0b3RhbCBwYWdlcyBpbiBjb3JlDQogICAgICA5NzY5 > IGN1cnJlbnQgY29yZSBtYXhpbXVtIHBhZ2VzDQogICAgICAgMjE2IHBhZ2Vz > IHJlc2VydmVkIGZvciBnYw0KICAgMzUxOTYxNCBwYWdlcyBhdmFpbGFibGUg > Zm9yIGFkZGluZyB0byBjb3JlDQogICAgIDM1NTU2IHBhZ2VzIHJlc2VydmVk > IGZvciBjb3JlIGV4aGF1c3Rpb24NCg0KICAgMzU2NTE1NSBtYXhpbXVtIHBh > Z2VzDQoNCg0KS2V5Og0KDQpXUzogd29yZHMgcGVyIHN0cnVjdA0KVVA6IGFs > bG9jYXRlZCBwYWdlcw0KTVA6IG1heGltdW0gcGFnZXMNCkZJOiBmcmFjdGlv > biBvZiBjZWxscyBpbiB1c2Ugb24gYWxsb2NhdGVkIHBhZ2VzDQpHQzogbnVt > YmVyIG9mIGdjIHRyaWdnZXJzIGFsbG9jYXRpbmcgdGhpcyB0eXBlDQoNCndv > cmQgc2l6ZTogICAgICAgICAgICA2NCBiaXRzDQpwYWdlIHNpemU6ICAgICAg > ICAgICAgNDA5NiBieXRlcw0KaGVhcCBzdGFydDogICAgICAgICAgIDB4RTgx > MDAwDQpoZWFwIG1heCA6ICAgICAgICAgICAgMHgzNjgzNjUwMDANCnNoYXJl > ZCBsaWJyYXJ5IHN0YXJ0OiAweDANCmNzdGFjayBzdGFydDogICAgICAgICAw > eDANCmNzdGFjayBtYXJrIG9mZnNldDogICAwIGJ5dGVzDQpjc3RhY2sgZGly > ZWN0aW9uOiAgICAgZG93bndhcmQNCmNzdGFjayBhbGlnbm1lbnQ6ICAgICAz > MiBieXRlcw0KY3N0YWNrIG1heDogICAgICAgICAgIDE2MDAxIGJ5dGVzDQpp > bW1maXggc3RhcnQ6ICAgICAgICAgMHg4MDAwMDAwMDAwMDAwMDAwDQppbW1m > aXggc2l6ZTogICAgICAgICAgNDYxMTY4NjAxODQyNzM4NzkwNCBmaXhudW1z > DQpwaHlzaWNhbCBtZW1vcnk6ICAgICAgMTI5OTUzNCBwYWdlcw0KKCVpMSkg > DSglaTEpIDpsaXNwIChzZXRxIHNpOjoqbm90aWZ5LWdiYyogdCkNCg0NClQN > CiglaTEpIA0oJWkxKSBydW5fdGVzdHN1aXRlKCk7DQoNUnVubmluZyB0ZXN0 > cyBpbiBydGVzdF9ydWxlczogMTAzLzEwMyB0ZXN0cyBwYXNzZWQNClJ1bm5p > bmcgdGVzdHMgaW4gcnRlc3Ruc2V0OiA1OTcvNTk3IHRlc3RzIHBhc3NlZA0K > UnVubmluZyB0ZXN0cyBpbiBydGVzdDE6IDE4MC8xODAgdGVzdHMgcGFzc2Vk > IChub3QgY291bnRpbmcgMSBleHBlY3RlZCBlcnJvcnMpDQpSdW5uaW5nIHRl > c3RzIGluIHJ0ZXN0MWE6IDI3LzI3IHRlc3RzIHBhc3NlZA0KUnVubmluZyB0 > ZXN0cyBpbiBydGVzdDI6IDE0NC8xNDQgdGVzdHMgcGFzc2VkIChub3QgY291 > bnRpbmcgMiBleHBlY3RlZCBlcnJvcnMpDQpSdW5uaW5nIHRlc3RzIGluIHJ0 > ZXN0NDogOTMvOTMgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0 > ZXN0NTogDQoqKioqKioqKioqKioqKioqKioqKioqIFByb2JsZW0gNzggKioq > KioqKioqKioqKioqDQpJbnB1dDoNCmRlc2NyaWJlKHNpbikNCg0KDQpSZXN1 > bHQ6DQoNCmVycm9yLWNhdGNoDQoNClRoaXMgZGlmZmVyZWQgZnJvbSB0aGUg > ZXhwZWN0ZWQgcmVzdWx0Og0KdHJ1ZQ0Kc3RhcnQgYWRkcmVzcyAtVCAweDI4 > ZWUwMTAgc3RhcnQgYWRkcmVzcyAtVCAweDI5MWU2NTAgc3RhcnQgYWRkcmVz > cyAtVCAweDI5MjVjZTAgc3RhcnQgYWRkcmVzcyAtVCAweDI5MmExYTAgc3Rh > cnQgYWRkcmVzcyAtVCAweDI5MmU2NjAgc3RhcnQgYWRkcmVzcyAtVCAweDI5 > MzZmMjAgc3RhcnQgYWRkcmVzcyAtVCAweDI5M2MwMTAgc3RhcnQgYWRkcmVz > cyAtVCAweDI5M2ZiNzAgDQo3OS84MCB0ZXN0cyBwYXNzZWQNCg0KVGhlIGZv > bGxvd2luZyAxIHByb2JsZW0gZmFpbGVkOiAoNzgpDQpSdW5uaW5nIHRlc3Rz > IGluIHJ0ZXN0NjogMzkvMzkgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3Rz > IGluIHJ0ZXN0NmE6IDYyLzYyIHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0 > cyBpbiBydGVzdDZiOiAxNi8xNiB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVz > dHMgaW4gcnRlc3Q3OiA4NS84NSB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVz > dHMgaW4gcnRlc3Q5OiA4OS84OSB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVz > dHMgaW4gcnRlc3Q5YTogNzYvNzYgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRl > c3RzIGluIHJ0ZXN0MTA6IDYyLzYyIHRlc3RzIHBhc3NlZCAobm90IGNvdW50 > aW5nIDIgZXhwZWN0ZWQgZXJyb3JzKQ0KUnVubmluZyB0ZXN0cyBpbiBydGVz > dDExOiAxODEvMTgxIHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0cyBpbiBy > dGVzdDEzOiAyMy8yMyB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4g > cnRlc3QxM3M6IDE3LzE3IHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0cyBp > biBydGVzdDE0OiBbR0MgZm9yIDIzNDU0NyBDT05TIHBhZ2VzLi4oVD0yNSku > R0MgZmluaXNoZWRdDQpbR0MgZm9yIDE4ODgxMyBSRUxPQ0FUQUJMRS1CTE9D > S1MgcGFnZXMuLihUPTE5KS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMTQwMTQ5 > IFNUUlVDVFVSRSBwYWdlcy4uKFQ9MjEpLkdDIGZpbmlzaGVkXQ0KNDE4LzQx > OCB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3QxNTogW0dD > IGZvciAyMzQ1NDcgQ09OUyBwYWdlcy4uKFQ9MTgpLkdDIGZpbmlzaGVkXQ0K > MzM0LzMzNCB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3Qx > NjogNTQwLzU0MCB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRl > c3RvZGU6IDkwLzkwIHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0cyBpbiBy > dGVzdG9kZV96cDogMzAvMzAgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3Rz > IGluIHJ0ZXN0MzogW0dDIGZvciAyMzU5NTcgQ09OUyBwYWdlcy4uKFQ9MjIp > LkdDIGZpbmlzaGVkXQ0KMTQ5LzE0OSB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcg > dGVzdHMgaW4gcnRlc3Q4OiAxNjQvMTY0IHRlc3RzIHBhc3NlZA0KUnVubmlu > ZyB0ZXN0cyBpbiBydGVzdDEyOiA3OS83OSB0ZXN0cyBwYXNzZWQgKG5vdCBj > b3VudGluZyAyIGV4cGVjdGVkIGVycm9ycykNClJ1bm5pbmcgdGVzdHMgaW4g > cmV4YW1wbGVzOiAxMzcvMTM3IHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0 > cyBpbiBydGVzdGh5cDogW0dDIGZvciAxNjU3NCBTRlVOIHBhZ2VzLi4oVD0x > NCkuR0MgZmluaXNoZWRdDQo0MjMvNDIzIHRlc3RzIHBhc3NlZCAobm90IGNv > dW50aW5nIDYgZXhwZWN0ZWQgZXJyb3JzKQ0KUnVubmluZyB0ZXN0cyBpbiBy > dGVzdF9oeXBnZW86IDI5MS8yOTEgdGVzdHMgcGFzc2VkIChub3QgY291bnRp > bmcgMSBleHBlY3RlZCBlcnJvcnMpDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0 > bXQxOTkzNzogMTUvMTUgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGlu > IHJ0ZXN0X2FsbG51bW1vZDogNTQ0LzU0NCB0ZXN0cyBwYXNzZWQNClJ1bm5p > bmcgdGVzdHMgaW4gcnRlc3Rjb25qdWdhdGU6IDEzNi8xMzYgdGVzdHMgcGFz > c2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0c3VtOiAzMDYvMzA2IHRlc3Rz > IHBhc3NlZCAobm90IGNvdW50aW5nIDQgZXhwZWN0ZWQgZXJyb3JzKQ0KUnVu > bmluZyB0ZXN0cyBpbiBydGVzdF90cmlnOiAxNjAvMTYwIHRlc3RzIHBhc3Nl > ZA0KUnVubmluZyB0ZXN0cyBpbiBydGVzdF96ZXRhOiAyMi8yMiB0ZXN0cyBw > YXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3RfZGlmZl9pbnZ0cmlnOiAy > Mi8yMiB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3Rfc2Nh > bGFycDogMjAvMjAgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0 > ZXN0X2V2ZXJ5c29tZTogODQvODQgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRl > c3RzIGluIHJ0ZXN0aW50OiBbR0MgZm9yIDE5OTMxMiBSRUxPQ0FUQUJMRS1C > TE9DS1MgcGFnZXMuLihUPTIwKS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjk5 > MiBTWU1CT0wgcGFnZXMuLihUPTIxKS5HQyBmaW5pc2hlZF0NCjI4Ny8yODcg > dGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X251bXRoOiBb > R0MgZm9yIDIzNTk1NyBDT05TIHBhZ2VzLi4oVD0yMikuR0MgZmluaXNoZWRd > DQoyMDEvMjAxIHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0cyBpbiBydGVz > dGlmYWN0b3I6IDI1LzI1IHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0cyBp > biBydGVzdF9lcXVhbDogMjA3LzIwNyB0ZXN0cyBwYXNzZWQgKG5vdCBjb3Vu > dGluZyAyIGV4cGVjdGVkIGVycm9ycykNClJ1bm5pbmcgdGVzdHMgaW4gcnRl > c3RfYWJzOiA5My85MyB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4g > cnRlc3RfdGF5bG9yOiBbR0MgZm9yIDIzNTk1NyBDT05TIHBhZ2VzLi4oVD0y > MikuR0MgZmluaXNoZWRdDQpbR0MgZm9yIDE4NjYwIEFSUkFZIHBhZ2VzLi4o > VD0yMCkuR0MgZmluaXNoZWRdDQoxNDkvMTQ5IHRlc3RzIHBhc3NlZCAobm90 > IGNvdW50aW5nIDggZXhwZWN0ZWQgZXJyb3JzKQ0KUnVubmluZyB0ZXN0cyBp > biBydGVzdF9kb3Q6IDYwLzYwIHRlc3RzIHBhc3NlZA0KUnVubmluZyB0ZXN0 > cyBpbiBydGVzdF9tc2V0OiA5Mi85MiB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcg > dGVzdHMgaW4gcnRlc3RfYm9vbGVhbjogMTE2LzExNiB0ZXN0cyBwYXNzZWQN > ClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3Rfcm91bmQ6IDEwMS8xMDEgdGVzdHMg > cGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X21hcDogOTkvOTkgdGVz > dHMgcGFzc2VkIChub3QgY291bnRpbmcgMyBleHBlY3RlZCBlcnJvcnMpDQpS > dW5uaW5nIHRlc3RzIGluIHJ0ZXN0X3NpZ246IDMyNi8zMjYgdGVzdHMgcGFz > c2VkIChub3QgY291bnRpbmcgNyBleHBlY3RlZCBlcnJvcnMpDQpSdW5uaW5n > IHRlc3RzIGluIHJ0ZXN0X2FsZ2VicmFpYzogW0dDIGZvciAyMjY5OSBBUlJB > WSBwYWdlcy4uKFQ9MjApLkdDIGZpbmlzaGVkXQ0KNDUvNDUgdGVzdHMgcGFz > c2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X2dhbW1hOiBbR0MgZm9yIDIy > NTQ3NSBSRUxPQ0FUQUJMRS1CTE9DS1MgcGFnZXMuLihUPTE3KS5HQyBmaW5p > c2hlZF0NCltHQyBmb3IgMTQwMTQ5IFNUUlVDVFVSRSBwYWdlcy4uKFQ9MjQp > LkdDIGZpbmlzaGVkXQ0KW0dDIGZvciAyNTU2MTggUkVMT0NBVEFCTEUtQkxP > Q0tTIHBhZ2VzLi4oVD0xNykuR0MgZmluaXNoZWRdDQo3NDcvNzQ3IHRlc3Rz > IHBhc3NlZA0KUnVubmluZyB0ZXN0cyBpbiBydGVzdF9leHBpbnRlZ3JhbDog > W0dDIGZvciAxNDAxNDkgU1RSVUNUVVJFIHBhZ2VzLi4oVD0yNCkuR0MgZmlu > aXNoZWRdDQpbR0MgZm9yIDI1NTYxOCBSRUxPQ0FUQUJMRS1CTE9DS1MgcGFn > ZXMuLihUPTE4KS5HQyBmaW5pc2hlZF0NCjIxMC8yMTAgdGVzdHMgcGFzc2Vk > DQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X3NpZ251bTogNTAvNTAgdGVzdHMg > cGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X2xhbWJlcnRfdzogNTcv > NTcgdGVzdHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X2VsbGlw > dGljOiBbR0MgZm9yIDMzMDggU1lNQk9MIHBhZ2VzLi4oVD0yNCkuR0MgZmlu > aXNoZWRdDQo4Ny84NyB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4g > cnRlc3RfaW50ZWdyYXRlOiBbR0MgZm9yIDI3MjY0IFNGVU4gcGFnZXMuLihU > PTIyKS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMzMwOCBTWU1CT0wgcGFnZXMu > LihUPTIxKS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjI2OTkgQVJSQVkgcGFn > ZXMuLihUPTE5KS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjI2OTkgQVJSQVkg > cGFnZXMuLihUPTE5KS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjI2OTkgQVJS > QVkgcGFnZXMuLihUPTE4KS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjI2OTkg > QVJSQVkgcGFnZXMuLihUPTIxKS5HQyBmaW5pc2hlZF0NCltHQyBmb3IgMjYw > MTQ1IFJFTE9DQVRBQkxFLUJMT0NLUyBwYWdlcy4uKFQ9MTcpLkdDIGZpbmlz > aGVkXQ0KW0dDIGZvciAyMzU5NTcgQ09OUyBwYWdlcy4uKFQ9MjIpLkdDIGZp > bmlzaGVkXQ0KW0dDIGZvciAyMzU5NTcgQ09OUyBwYWdlcy4uKFQ9MjIpLkdD > IGZpbmlzaGVkXQ0KODEyLzgxMiB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVz > dHMgaW4gcnRlc3RfaW50ZWdyYXRlX3NwZWNpYWw6IDUzLzUzIHRlc3RzIHBh > c3NlZA0KUnVubmluZyB0ZXN0cyBpbiBydGVzdF9zcXJ0OiAzMTMvMzEzIHRl > c3RzIHBhc3NlZCAobm90IGNvdW50aW5nIDEgZXhwZWN0ZWQgZXJyb3JzKQ0K > UnVubmluZyB0ZXN0cyBpbiBydGVzdF9jYXJnOiA1NS81NSB0ZXN0cyBwYXNz > ZWQgKG5vdCBjb3VudGluZyAyIGV4cGVjdGVkIGVycm9ycykNClJ1bm5pbmcg > dGVzdHMgaW4gcnRlc3RfbG9nOiBbR0MgZm9yIDIzNTk1NyBDT05TIHBhZ2Vz > Li4oVD0yMykuR0MgZmluaXNoZWRdDQoxMjEvMTIxIHRlc3RzIHBhc3NlZA0K > UnVubmluZyB0ZXN0cyBpbiBydGVzdF9wb3dlcjogNzIvNzIgdGVzdHMgcGFz > c2VkIChub3QgY291bnRpbmcgNSBleHBlY3RlZCBlcnJvcnMpDQpSdW5uaW5n > IHRlc3RzIGluIHJ0ZXN0ZGVmc3RydWN0OiAzMi8zMiB0ZXN0cyBwYXNzZWQN > ClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3RfbGltaXQ6IFtHQyBmb3IgMjM1OTU3 > IENPTlMgcGFnZXMuLihUPTIzKS5HQyBmaW5pc2hlZF0NCjIwMC8yMDAgdGVz > dHMgcGFzc2VkDQpSdW5uaW5nIHRlc3RzIGluIHJ0ZXN0X3Bvd2Vyc2VyaWVz > OiA2Ny82NyB0ZXN0cyBwYXNzZWQNClJ1bm5pbmcgdGVzdHMgaW4gcnRlc3Rf > bGFwbGFjZTogOTgvOTggdGVzdHMgcGFzc2VkIChub3QgY291bnRpbmcgMTEg > ZXhwZWN0ZWQgZXJyb3JzKQ0KUnVubmluZyB0ZXN0cyBpbiBydGVzdF9wbG90 > b3B0aW9uczogMS8xIHRlc3RzIHBhc3NlZA0KDQpFcnJvciBzdW1tYXJ5Og0K > RXJyb3IgZm91bmQgaW4gL3Vzci9zaGFyZS9tYXhpbWEvNS4zOC4wL3Rlc3Rz > L3J0ZXN0NS5tYWMsIHByb2JsZW06DQooNzgpDQoxIHRlc3QgZmFpbGVkIG91 > dCBvZiAxMCw2MTQgdG90YWwgdGVzdHMuDQpyZWFsIHRpbWUgICAgICAgOiAg > ICAgODIuNTQwIHNlY3MNCnJ1bi1nYmMgdGltZSAgICA6ICAgICA3Mi4wNTkg > c2Vjcw0KY2hpbGQgcnVuIHRpbWUgIDogICAgICAwLjM2MCBzZWNzDQpnYmMg > dGltZSAgICAgICAgOiAgICAgIDUuOTQ5IHNlY3MNCiglbzApICAgICAgICAg > ICAgICAgICAgICAgICAgICAgICAgICBkb25lDQooJWkxKSANKCVpMSkgOmxp > c3AgKHJvb20gdCkNCg0NCiAgMjM1OTU3LzIzNTk1NyAgICAgIDk0LjglICAg > ICAgIDkgQ09OUyBGSVhOVU0gU0hPUlQtRkxPQVQgTE9ORy1GTE9BVCBCSVQt > VkVDVE9SIFBBVEhOQU1FIFNQSUNFDQogICAyMjY5OS8yMjY5OSAgICAgICAz > OS41JSAgICAgICA2IEFSUkFZIENIQVJBQ1RFUiBQQUNLQUdFIEhBU0gtVEFC > TEUgVkVDVE9SIFJBTkRPTS1TVEFURSBDQ0xPU1VSRSBDTE9TVVJFDQogIDE0 > MDE0OS8xNDAxNDkgICAgICAgMC4zJSAgICAgICAzIFNUUklORyBCSUdOVU0g > UkFUSU8gQ09NUExFWA0KICAgIDMzMDgvMzMwOCAgICAgICAgODcuMSUgICAg > ICAgMyBTVFJVQ1RVUkUNCiAgICAgICAxLzEgICAgICAgICAgIDY1LjIlICAg > ICAgICAgU1RSRUFNDQogICAgICA0OC80OCAgICAgICAgICA5OS4zJSAgICAg > ICAgIENGVU4gQ0ZEQVRBDQogICAyNzI2NC8yNzI2NCAgICAgICA0NC4xJSAg > ICAgICAyIFNGVU4gU1lNQk9MIFJFQURUQUJMRSBHRlVOIFZGVU4gQUZVTg0K > DQogICAgNzE2OC83MTY4ICAgICAgICAgICAgICAgICAgICAgIGNvbnRpZ3Vv > dXMgKDEgYmxvY2tzKQ0KICAgICAgICAgNzAxMTI3ICAgICAgICAgICAgICAg > ICAgICBob2xlDQogIDI2MDE0NS8yNjAxNDUgICAgICAyMS4zJSAgICAgICA2 > IHJlbG9jYXRhYmxlDQoNCiAgICA0Mjk0MjYgcGFnZXMgZm9yIGNlbGxzDQoN > CiAgICA2OTY3MzkgdG90YWwgcGFnZXMgaW4gY29yZQ0KICAgIDY5NjczOSBj > dXJyZW50IGNvcmUgbWF4aW11bSBwYWdlcw0KICAgIDI2MDE0NSBwYWdlcyBy > ZXNlcnZlZCBmb3IgZ2MNCiAgIDI1NzI3MTUgcGFnZXMgYXZhaWxhYmxlIGZv > ciBhZGRpbmcgdG8gY29yZQ0KICAgICAzNTU1NiBwYWdlcyByZXNlcnZlZCBm > b3IgY29yZSBleGhhdXN0aW9uDQoNCiAgIDM1NjUxNTUgbWF4aW11bSBwYWdl > cw0KDQoNCktleToNCg0KV1M6IHdvcmRzIHBlciBzdHJ1Y3QNClVQOiBhbGxv > Y2F0ZWQgcGFnZXMNCk1QOiBtYXhpbXVtIHBhZ2VzDQpGSTogZnJhY3Rpb24g > b2YgY2VsbHMgaW4gdXNlIG9uIGFsbG9jYXRlZCBwYWdlcw0KR0M6IG51bWJl > ciBvZiBnYyB0cmlnZ2VycyBhbGxvY2F0aW5nIHRoaXMgdHlwZQ0KDQp3b3Jk > IHNpemU6ICAgICAgICAgICAgNjQgYml0cw0KcGFnZSBzaXplOiAgICAgICAg > ICAgIDQwOTYgYnl0ZXMNCmhlYXAgc3RhcnQ6ICAgICAgICAgICAweEU4MTAw > MA0KaGVhcCBtYXggOiAgICAgICAgICAgIDB4MzY4MzY1MDAwDQpzaGFyZWQg > bGlicmFyeSBzdGFydDogMHgwDQpjc3RhY2sgc3RhcnQ6ICAgICAgICAgMHgw > DQpjc3RhY2sgbWFyayBvZmZzZXQ6ICAgMCBieXRlcw0KY3N0YWNrIGRpcmVj > dGlvbjogICAgIGRvd253YXJkDQpjc3RhY2sgYWxpZ25tZW50OiAgICAgMzIg > Ynl0ZXMNCmNzdGFjayBtYXg6ICAgICAgICAgICAxNjAwMSBieXRlcw0KaW1t > Zml4IHN0YXJ0OiAgICAgICAgIDB4ODAwMDAwMDAwMDAwMDAwMA0KaW1tZml4 > IHNpemU6ICAgICAgICAgIDQ2MTE2ODYwMTg0MjczODc5MDQgZml4bnVtcw0K > cGh5c2ljYWwgbWVtb3J5OiAgICAgIDEyOTk1MzQgcGFnZXMNCg== > > --1555662558-153843084-1472425557=:7248-- > From unknown Mon Sep 26 19:22:45 2016 > X-Loop: ow...@bugs.debian.org > Subject: Bug#827953: maxima: Uses too much memory to build > Reply-To: Camm Maguire <c...@maguirefamily.org>, 827...@bugs.debian.org > Resent-From: Camm Maguire <c...@maguirefamily.org> > Resent-To: debian-bugs-dist@lists.debian.org > Resent-CC: Camm Maguire <c...@debian.org> > X-Loop: ow...@bugs.debian.org > Resent-Date: Tue, 13 Sep 2016 22:27:08 +0000 > Resent-Message-ID: <handler.827953.b827953.14738053948...@bugs.debian.org> > Resent-Sender: ow...@bugs.debian.org > X-Debian-PR-Message: followup 827953 > X-Debian-PR-Package: maxima > X-Debian-PR-Keywords: > X-Debian-PR-Source: maxima > Received: via spool by 827953-sub...@bugs.debian.org id=B827953.14738053948594 > (code B ref 827953); Tue, 13 Sep 2016 22:27:08 +0000 > Received: (at 827953) by bugs.debian.org; 13 Sep 2016 22:23:14 +0000 > X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02 > (2014-02-07) on buxtehude.debian.org > X-Spam-Level: > X-Spam-Status: No, score=-3.4 required=4.0 tests=BAYES_00,DIGITS_LETTERS, > > FOURLA,HAS_BUG_NUMBER,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, > RCVD_IN_MSPIKE_WL,T_HDRS_LCASE,T_MANY_HDRS_LCASE,URIBL_CNKR autolearn=no > autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02 > X-Spam-Bayes: score:0.0000 Tokens: new, 13; hammy, 148; neutral, 483; spammy, > 2. spammytokens:0.999-1--3.9gb, 0.999-1--39gb > hammytokens:0.000-+--H*f:sk:alpine., 0.000-+--H*u:Gnus, > 0.000-+--H*u:linux, > 0.000-+--H*UA:linux, 0.000-+--H*u:gnu > Received: from vms173017pub.verizon.net ([206.46.173.17]) > by buxtehude.debian.org with esmtps > (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) > (Exim 4.84_2) > (envelope-from <c...@maguirefamily.org>) > id 1bjw6j-0002Dd-NW > for 827...@bugs.debian.org; Tue, 13 Sep 2016 22:23:14 +0000 > Received: from vz-proxy-m004.mx.aol.com ([64.236.83.8]) > by vms173017.mailsrvcs.net > (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) > with ESMTPA id <0odg00fs7opmy...@vms173017.mailsrvcs.net> for > 827...@bugs.debian.org; Tue, 13 Sep 2016 16:22:35 -0500 (CDT) > X-CMAE-Score: 0 > X-CMAE-Analysis: v=2.1 cv=Nc0brD34 c=1 sm=1 tr=0 > a=Bcm0RCOkHTZ4We9DUxtllQ==:117 > a=kj9zAlcOel0A:10 a=GW1xBdLrtEIA:10 a=FP58Ms26AAAA:8 a=9N09Ue-cAAAA:8 > a=7EHtaSwGMAO1KnLjdqoA:9 a=aXQrydeB70DOgFrA:21 a=JsSh0JamHMAANGif:21 > a=CjuIK1q_8ugA:10 > Received: by 173.61.133.218 with SMTP id 7652ff78; Tue, 13 Sep 2016 21:22:35 > GMT > Received: from camm by localhost.m.enhanced.com with local (Exim 4.80) > (envelope-from <c...@maguirefamily.org>) id 1bjv9Q-0001zH-EI; > Tue, > 13 Sep 2016 17:21:56 -0400 > From: Camm Maguire <c...@maguirefamily.org> > To: Santiago Vila <sanv...@unex.es> > Cc: 827...@bugs.debian.org > References: <alpine.deb.2.20.1606231120560.19...@cantor.unex.es> > <874m7x36hc....@maguirefamily.org> > <alpine.deb.2.11.1607251101430.3...@tulipan.isla-invisible.es> > <87h9bdpy7n....@maguirefamily.org> > <alpine.deb.2.11.1608290058270.7...@tulipan.isla-invisible.es> > Date: Tue, 13 Sep 2016 17:21:56 -0400 > In-reply-to: <alpine.deb.2.11.1608290058270.7...@tulipan.isla-invisible.es> > (Santiago Vila's message of "Mon, 29 Aug 2016 01:05:55 +0200 (CEST)") > Message-id: <878tuvo5qj....@maguirefamily.org> > User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > X-Greylist: delayed 3609 seconds by postgrey-1.35 at buxtehude; Tue, 13 Sep > 2016 22:23:13 UTC > > Greetings, and thanks so much! > > It appears that all is working as intended, that gc is triggered and > keeping the active heap to about 2.8Gb (or 3.9Gb with relocatable copy > area) of a detected max of 5.3Gb (see core pages, and physical memory). > At the end of this experiment, the rss of this process as viewed from a > separate shell should confirm these figures. So I do not think gcl is > expanding into swap here. > > As for the /proc/meminfo, all I can say is that the build employs many > other programs as well. Might be interesting to correlate this figure > with the various stages of the build. In other words, how much just to > run the debian/rules build target, etc. > > Santiago Vila <sanv...@unex.es> writes: > >> On Mon, 25 Jul 2016, Camm Maguire wrote: >> >>> If this is happening, then it is indeed a bug. The intent is to use >>> physical ram only by default unless the application itself insists on >>> more. Going into swap by default obviously defeats the performance goal >>> of expanding the memory anyway. You can look into this by >>> >>> gcl >>> >(room t) >>> >>> and >>> >>> maxima >>> (..) :lisp (room t) >>> (..) :lisp (setq si::*notify-gbc* t) >>> (..) run_testsuite(); >>> (..) :lisp (room t) >>> >>> If you can post the results for this on the 4/4 machine you describe >>> above I can see if we have a problem. >> >> Sorry for the late reply. >> >> I attach the results for maxima, on a machine with 6GB RAM and 4GB swap. >> >> I don't know how to interpret the results. In addition to the test you >> requested, when I do this >> >> grep "Committed_AS:" /proc/meminfo >> >> I get this before running maxima: >> >> Committed_AS: 254276 kB >> >> and this after the test finished, before exiting maxima: >> >> Committed_AS: 6878284 kB >> >> I guess this does still not explain why Committed_AS: grows so much >> when I'm actually trying to build the Debian package. >> >> Thanks. >> >> (sid)buildd@skywalker1:~$ maxima >> >> Maxima 5.38.0 http://maxima.sourceforge.net >> using Lisp GNU Common Lisp (GCL) GCL 2.6.12 >> Distributed under the GNU Public License. See the file COPYING. >> Dedicated to the memory of William Schelter. >> The function bug_report() provides bug reporting information. >> (%i1) (%i1) :lisp (room t) >> >> 1828/1828 88.8% CONS FIXNUM SHORT-FLOAT LONG-FLOAT >> BIT-VECTOR PATHNAME SPICE >> 220/220 99.8% ARRAY CHARACTER PACKAGE HASH-TABLE VECTOR >> RANDOM-STATE CCLOSURE CLOSURE >> 67/67 56.7% STRING BIGNUM RATIO COMPLEX >> 399/399 98.8% STRUCTURE >> 1/1 65.2% STREAM >> 46/46 99.4% CFUN CFDATA >> 592/592 99.8% SFUN SYMBOL READTABLE GFUN VFUN AFUN >> >> 6400/6400 contiguous (30 blocks) >> 1173337 hole >> 216/216 99.9% relocatable >> >> 3153 pages for cells >> >> 9769 total pages in core >> 9769 current core maximum pages >> 216 pages reserved for gc >> 3519614 pages available for adding to core >> 35556 pages reserved for core exhaustion >> >> 3565155 maximum pages >> >> >> Key: >> >> WS: words per struct >> UP: allocated pages >> MP: maximum pages >> FI: fraction of cells in use on allocated pages >> GC: number of gc triggers allocating this type >> >> word size: 64 bits >> page size: 4096 bytes >> heap start: 0xE81000 >> heap max : 0x368365000 >> shared library start: 0x0 >> cstack start: 0x0 >> cstack mark offset: 0 bytes >> cstack direction: downward >> cstack alignment: 32 bytes >> cstack max: 16001 bytes >> immfix start: 0x8000000000000000 >> immfix size: 4611686018427387904 fixnums >> physical memory: 1299534 pages >> (%i1) (%i1) :lisp (setq si::*notify-gbc* t) >> >> T >> (%i1) (%i1) run_testsuite(); >> Running tests in rtest_rules: 103/103 tests passed >> Running tests in rtestnset: 597/597 tests passed >> Running tests in rtest1: 180/180 tests passed (not counting 1 expected >> errors) >> Running tests in rtest1a: 27/27 tests passed >> Running tests in rtest2: 144/144 tests passed (not counting 2 expected >> errors) >> Running tests in rtest4: 93/93 tests passed >> Running tests in rtest5: >> ********************** Problem 78 *************** >> Input: >> describe(sin) >> >> >> Result: >> >> error-catch >> >> This differed from the expected result: >> true >> start address -T 0x28ee010 start address -T 0x291e650 start address -T >> 0x2925ce0 start address -T 0x292a1a0 start address -T 0x292e660 start >> address -T 0x2936f20 start address -T 0x293c010 start address -T 0x293fb70 >> 79/80 tests passed >> >> The following 1 problem failed: (78) >> Running tests in rtest6: 39/39 tests passed >> Running tests in rtest6a: 62/62 tests passed >> Running tests in rtest6b: 16/16 tests passed >> Running tests in rtest7: 85/85 tests passed >> Running tests in rtest9: 89/89 tests passed >> Running tests in rtest9a: 76/76 tests passed >> Running tests in rtest10: 62/62 tests passed (not counting 2 expected errors) >> Running tests in rtest11: 181/181 tests passed >> Running tests in rtest13: 23/23 tests passed >> Running tests in rtest13s: 17/17 tests passed >> Running tests in rtest14: [GC for 234547 CONS pages..(T=25).GC finished] >> [GC for 188813 RELOCATABLE-BLOCKS pages..(T=19).GC finished] >> [GC for 140149 STRUCTURE pages..(T=21).GC finished] >> 418/418 tests passed >> Running tests in rtest15: [GC for 234547 CONS pages..(T=18).GC finished] >> 334/334 tests passed >> Running tests in rtest16: 540/540 tests passed >> Running tests in rtestode: 90/90 tests passed >> Running tests in rtestode_zp: 30/30 tests passed >> Running tests in rtest3: [GC for 235957 CONS pages..(T=22).GC finished] >> 149/149 tests passed >> Running tests in rtest8: 164/164 tests passed >> Running tests in rtest12: 79/79 tests passed (not counting 2 expected errors) >> Running tests in rexamples: 137/137 tests passed >> Running tests in rtesthyp: [GC for 16574 SFUN pages..(T=14).GC finished] >> 423/423 tests passed (not counting 6 expected errors) >> Running tests in rtest_hypgeo: 291/291 tests passed (not counting 1 expected >> errors) >> Running tests in rtestmt19937: 15/15 tests passed >> Running tests in rtest_allnummod: 544/544 tests passed >> Running tests in rtestconjugate: 136/136 tests passed >> Running tests in rtestsum: 306/306 tests passed (not counting 4 expected >> errors) >> Running tests in rtest_trig: 160/160 tests passed >> Running tests in rtest_zeta: 22/22 tests passed >> Running tests in rtest_diff_invtrig: 22/22 tests passed >> Running tests in rtest_scalarp: 20/20 tests passed >> Running tests in rtest_everysome: 84/84 tests passed >> Running tests in rtestint: [GC for 199312 RELOCATABLE-BLOCKS >> pages..(T=20).GC finished] >> [GC for 2992 SYMBOL pages..(T=21).GC finished] >> 287/287 tests passed >> Running tests in rtest_numth: [GC for 235957 CONS pages..(T=22).GC finished] >> 201/201 tests passed >> Running tests in rtestifactor: 25/25 tests passed >> Running tests in rtest_equal: 207/207 tests passed (not counting 2 expected >> errors) >> Running tests in rtest_abs: 93/93 tests passed >> Running tests in rtest_taylor: [GC for 235957 CONS pages..(T=22).GC finished] >> [GC for 18660 ARRAY pages..(T=20).GC finished] >> 149/149 tests passed (not counting 8 expected errors) >> Running tests in rtest_dot: 60/60 tests passed >> Running tests in rtest_mset: 92/92 tests passed >> Running tests in rtest_boolean: 116/116 tests passed >> Running tests in rtest_round: 101/101 tests passed >> Running tests in rtest_map: 99/99 tests passed (not counting 3 expected >> errors) >> Running tests in rtest_sign: 326/326 tests passed (not counting 7 expected >> errors) >> Running tests in rtest_algebraic: [GC for 22699 ARRAY pages..(T=20).GC >> finished] >> 45/45 tests passed >> Running tests in rtest_gamma: [GC for 225475 RELOCATABLE-BLOCKS >> pages..(T=17).GC finished] >> [GC for 140149 STRUCTURE pages..(T=24).GC finished] >> [GC for 255618 RELOCATABLE-BLOCKS pages..(T=17).GC finished] >> 747/747 tests passed >> Running tests in rtest_expintegral: [GC for 140149 STRUCTURE >> pages..(T=24).GC finished] >> [GC for 255618 RELOCATABLE-BLOCKS pages..(T=18).GC finished] >> 210/210 tests passed >> Running tests in rtest_signum: 50/50 tests passed >> Running tests in rtest_lambert_w: 57/57 tests passed >> Running tests in rtest_elliptic: [GC for 3308 SYMBOL pages..(T=24).GC >> finished] >> 87/87 tests passed >> Running tests in rtest_integrate: [GC for 27264 SFUN pages..(T=22).GC >> finished] >> [GC for 3308 SYMBOL pages..(T=21).GC finished] >> [GC for 22699 ARRAY pages..(T=19).GC finished] >> [GC for 22699 ARRAY pages..(T=19).GC finished] >> [GC for 22699 ARRAY pages..(T=18).GC finished] >> [GC for 22699 ARRAY pages..(T=21).GC finished] >> [GC for 260145 RELOCATABLE-BLOCKS pages..(T=17).GC finished] >> [GC for 235957 CONS pages..(T=22).GC finished] >> [GC for 235957 CONS pages..(T=22).GC finished] >> 812/812 tests passed >> Running tests in rtest_integrate_special: 53/53 tests passed >> Running tests in rtest_sqrt: 313/313 tests passed (not counting 1 expected >> errors) >> Running tests in rtest_carg: 55/55 tests passed (not counting 2 expected >> errors) >> Running tests in rtest_log: [GC for 235957 CONS pages..(T=23).GC finished] >> 121/121 tests passed >> Running tests in rtest_power: 72/72 tests passed (not counting 5 expected >> errors) >> Running tests in rtestdefstruct: 32/32 tests passed >> Running tests in rtest_limit: [GC for 235957 CONS pages..(T=23).GC finished] >> 200/200 tests passed >> Running tests in rtest_powerseries: 67/67 tests passed >> Running tests in rtest_laplace: 98/98 tests passed (not counting 11 expected >> errors) >> Running tests in rtest_plotoptions: 1/1 tests passed >> >> Error summary: >> Error found in /usr/share/maxima/5.38.0/tests/rtest5.mac, problem: >> (78) >> 1 test failed out of 10,614 total tests. >> real time : 82.540 secs >> run-gbc time : 72.059 secs >> child run time : 0.360 secs >> gbc time : 5.949 secs >> (%o0) done >> (%i1) (%i1) :lisp (room t) >> >> 235957/235957 94.8% 9 CONS FIXNUM SHORT-FLOAT LONG-FLOAT >> BIT-VECTOR PATHNAME SPICE >> 22699/22699 39.5% 6 ARRAY CHARACTER PACKAGE HASH-TABLE VECTOR >> RANDOM-STATE CCLOSURE CLOSURE >> 140149/140149 0.3% 3 STRING BIGNUM RATIO COMPLEX >> 3308/3308 87.1% 3 STRUCTURE >> 1/1 65.2% STREAM >> 48/48 99.3% CFUN CFDATA >> 27264/27264 44.1% 2 SFUN SYMBOL READTABLE GFUN VFUN AFUN >> >> 7168/7168 contiguous (1 blocks) >> 701127 hole >> 260145/260145 21.3% 6 relocatable >> >> 429426 pages for cells >> >> 696739 total pages in core >> 696739 current core maximum pages >> 260145 pages reserved for gc >> 2572715 pages available for adding to core >> 35556 pages reserved for core exhaustion >> >> 3565155 maximum pages >> >> >> Key: >> >> WS: words per struct >> UP: allocated pages >> MP: maximum pages >> FI: fraction of cells in use on allocated pages >> GC: number of gc triggers allocating this type >> >> word size: 64 bits >> page size: 4096 bytes >> heap start: 0xE81000 >> heap max : 0x368365000 >> shared library start: 0x0 >> cstack start: 0x0 >> cstack mark offset: 0 bytes >> cstack direction: downward >> cstack alignment: 32 bytes >> cstack max: 16001 bytes >> immfix start: 0x8000000000000000 >> immfix size: 4611686018427387904 fixnums >> physical memory: 1299534 pages -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
