unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: 39813@debbugs.gnu.org, raingloom@riseup.net, maxim.cournoyer@gmail.com
Cc: dannym@scratchpost.org, 39813-done@debbugs.gnu.org
Subject: bug#39813: Running Guix in a Virtual Machine - says 1 GB RAM is enough, but it isn't for guix pull
Date: Wed, 13 Jul 2022 19:21:45 +0200	[thread overview]
Message-ID: <F1E6A8E8-8FEE-464B-AB69-66F6625DF644@lepiller.eu> (raw)
In-Reply-To: <87lesx7xsx.fsf@riseup.net>

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

I've heard that theory before. From observation on my late armhf server (two cores):

- it takes just below 2GB to build one of the derivations
- It doesn't swap a single byte
- whether with two or a single core, it takes roughly the same amount of memory
- substitution is nice, it doesn't require lots of memory (and then --cores is useless)

I think it's because we load all the files in a batch before we build them. The biggest amount of memory required is not for running the compiler on a thread, but for loading files and keeping them in memory for the whole duration of the build. With more threads, we still don't load each file more than once (twice to build it), so there's no reason it should take more memory.

Or maybe the process of loading and building is inherently single-threaded? I don't think so, but maybe?

Or it doesn't honor --cores.

Le 13 juillet 2022 18:58:58 GMT+02:00, Csepp <raingloom@riseup.net> a écrit :
>
>Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi Danny,
>>
>> Danny Milosavljevic <dannym@scratchpost.org> writes:
>>
>>> Hi,
>>>
>>> I just got a report that with Guix in a virtual Machine (like described in the
>>> manual in 8.16), guix pull does not actually work[1] with 1 GB of RAM.
>>> It does work fine with 4 GB of RAM.
>>
>> I don't see any reference of 1 GiB being enough in our current version
>> of the manual.  If you do, please let me know.
>>
>> Closing for now.
>>
>> Thanks,
>>
>> Maxim
>
>I think it's enough if you only use a single core.
>If any guix operations goes out of memory, add --cores=1.
>So: guix pull --cores=1
>
>
>

[-- Attachment #2: Type: text/html, Size: 2205 bytes --]

  reply	other threads:[~2022-07-13 17:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 20:06 bug#39813: Running Guix in a Virtual Machine - says 1 GB RAM is enough, but it isn't for guix pull Danny Milosavljevic
2022-07-13 14:00 ` Maxim Cournoyer
2022-07-13 16:58   ` Csepp
2022-07-13 17:21     ` Julien Lepiller [this message]
2022-07-13 20:00       ` Liliana Marie Prikler
2022-07-14 12:50         ` Csepp

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://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F1E6A8E8-8FEE-464B-AB69-66F6625DF644@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=39813-done@debbugs.gnu.org \
    --cc=39813@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=raingloom@riseup.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).