From: Roland Orre <roland.orre@neurologic.se>
To: guile-user@gnu.org
Subject: Re: What is best way to limit memory alloc?
Date: Wed, 29 Aug 2007 12:22:47 +0200 [thread overview]
Message-ID: <1188382968.8043.578.camel@localhost.localdomain> (raw)
In-Reply-To: <1188367992.8043.508.camel@localhost.localdomain>
I found out that I had already solved the memory allocation
problem in one way a few years ago.
With the help of a small routine gc-heap-size, which accesses
scm_i_master_freelist.heap_size
scm_i_master_freelist2.heap_size
I did:
(define gc-heap1 (gc-heap-size 1))
(define gc-heap2 (gc-heap-size 2))
(let loop
....
(gc-heap-size 1 gc-heap1)
(gc-heap-size 2 gc-heap2)
(loop ...))
By not allowing the heap size to increase.
Then it worked, the memory just increased to
7.1 GB instead of 8.8 GB and it was then stable there during
the whole run. Is there any other better way to solve this?
I would like to be able to say something like:
don't allocate any memory above nn GB otherwise abort,
as a swapping guile process is just dead anyway.
The job now took just 19 minutes to finish, the other one
which is still swapping, has been running since Monday
(52 hours) and is just half ready...
/Roland
On Wed, 2007-08-29 at 08:13 +0200, Roland Orre wrote:
> What is the best way to limit the memory allocation in guile?
>
> I have a process that has allocated 6GB when the first step
> is finished, this is much, but is fine as the machine has 8 GB.
>
> Then when performing the last step, just involving reading
> from a file, doing some string split for each line, adding
> some data and writing it back to the file line per line, the
> memory suddenly increases to 8.8 GB and then the job starts
> swapping ridicously and stops of course.
>
> It seems as the memory allocator in guile doesn't care about
> the physical memory limits and it seems as it prefers to
> allocate big chunks of more memory instead of performing gc
> despite very little extra memory should be needed.
>
> I'm still running 1.7 as I haven't got the time and energy
> to change the array implementation yet.
>
> I assume I have to change something in gc.c, the simplest I
> would like to say is, don't allocate more memory than this!
>
> /Roland Orre
>
>
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2007-08-29 10:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-24 10:14 MMCI 1.1.1 available Thien-Thi Nguyen
[not found] ` <1188367992.8043.508.camel@localhost.localdomain>
2007-08-29 10:22 ` Roland Orre [this message]
2007-08-29 15:20 ` What is best way to limit memory alloc? Ludovic Courtès
2007-09-01 0:02 ` Kevin Ryde
2007-08-29 11:47 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1188382968.8043.578.camel@localhost.localdomain \
--to=roland.orre@neurologic.se \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).