unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org
Subject: [PATCH] DRAFT: build: Compile scheme modules in batches (was Re: Release!)
Date: Sat, 07 Oct 2017 00:06:51 -0400	[thread overview]
Message-ID: <87fuavzjms.fsf_-_@netris.org> (raw)
In-Reply-To: <87efqgnn7x.fsf@elephly.net> (Ricardo Wurmus's message of "Fri, 06 Oct 2017 20:30:10 +0200")

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Ludo,
>
>>> Here are some important items I can think of:
> […]
>>>   • Guile 2.2 compiler terrible issue:
>>>     <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
>
> One way to side-step this issue for the upcoming release is to use one
> Guile process per file when running “guix pull”.  This will make it run
> a lot slower, but that would be better than the current situation.

I've attached a workaround that I've been using for the last 6 weeks on
my MIPS-based Yeeloong running GuixSD, since it only has 1 GB of RAM and
otherwise it would not be able to successfully build the 'guix' package.

Note that I never use 'guix pull', so I'm not sure off-hand whether this
solves the problem there, but it certainly greatly reduces the memory
needed to run 'make' and thus to build the 'guix' package.

This patch modifies build-aux/compile-all.scm to work as follows: after
loading all modules in the parent process, it then forks off a child and
compiles 20 modules in parallel within that child while the parent
waits.  When the child is finished compiling those 20 modules, the child
exits (thus freeing the memory leaked during compilation), and then the
parent spawns a new child to compile the next 20 modules, and so on,
until all the modules are compiled.

We should probably consider applying this to master.  Thoughts?

      Mark



[-- Attachment #2: [PATCH] DRAFT: build: Compile scheme modules in batches --]
[-- Type: text/x-patch, Size: 3684 bytes --]

From 05d5581ff71eb3b48773a5d46b612202de0492fb Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Tue, 22 Aug 2017 03:26:10 -0400
Subject: [PATCH] DRAFT: build: Compile scheme modules in batches.

---
 build-aux/compile-all.scm | 48 ++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/build-aux/compile-all.scm b/build-aux/compile-all.scm
index 147bb8019..96658e069 100644
--- a/build-aux/compile-all.scm
+++ b/build-aux/compile-all.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 Taylan Ulrich Bayırlı/Kammer <taylanbayirli@gmail.com>
 ;;; Copyright © 2016, 2017 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2017 Mark H Weaver <mhw@netris.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,6 +20,7 @@
 
 (use-modules (system base target)
              (system base message)
+             (srfi srfi-1)
              (ice-9 match)
              (ice-9 threads)
              (guix build utils))
@@ -118,13 +120,45 @@
   ((_ . files)
    (let ((files (filter file-needs-compilation? files)))
      (for-each load-module-file files)
-     (let ((mutex (make-mutex)))
-       ;; Make sure compilation related modules are loaded before starting to
-       ;; compile files in parallel.
-       (compile #f)
-       (par-for-each (lambda (file)
-                       (compile-file* file mutex))
-                     files)))))
+     ;; Make sure compilation related modules are loaded before starting to
+     ;; compile files in parallel.
+     (compile #f)
+     ;; Flush all ports before entering the fork loop, to avoid flushing them
+     ;; more than once within the child processes created below.
+     (flush-all-ports)
+
+     ;; FIXME The following loop works around the apparent memory leak in the
+     ;; compiler of guile-2.2.2, where compiling scheme modules requires
+     ;; increasing amounts of memory, up to nearly 2 gigabytes when all guix
+     ;; sources are compiled within a single process.
+     ;;
+     ;; Ideally, we would simply apply 'par-for-each' to the entire set of
+     ;; files.  For now, to work around the memory leak, we spawn subprocesses
+     ;; to compile the files in batches of up to 20 files each.
+     (let fork-loop ((files files))
+       (unless (null? files)
+         (call-with-values (lambda ()
+                             (split-at files (min 20 (length files))))
+           (lambda (current-batch remaining-files)
+             ;; IMPORTANT: as noted in the Guile manual, it is unsafe to fork a
+             ;; process that has multiple threads running.  Here we avoid this
+             ;; difficulty by spawning threads only within the child processes,
+             ;; which never call fork.
+             (match (primitive-fork)
+               (0
+                ;; This is the child.  It spawns threads but never forks.
+                (let ((mutex (make-mutex)))
+                  (par-for-each (lambda (file)
+                                  (compile-file* file mutex))
+                                current-batch))
+                (primitive-exit))
+               (child-pid
+                ;; This is the parent.  It forks but never spawns threads.
+                (match (waitpid child-pid)
+                  ((_ . 0)
+                   (fork-loop remaining-files))
+                  ((_ . status)
+                   (primitive-exit (or (status:exit-val status) 1)))))))))))))
 
 ;;; Local Variables:
 ;;; eval: (put 'with-target 'scheme-indent-function 1)
-- 
2.14.1


  parent reply	other threads:[~2017-10-07  4:07 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24 13:11 What’s next? Ludovic Courtès
2017-05-24 13:23 ` Ricardo Wurmus
2017-05-27 10:01   ` Ludovic Courtès
2017-05-27 21:44     ` Ricardo Wurmus
2017-05-28 20:44       ` Ludovic Courtès
2017-05-28 21:36         ` Ricardo Wurmus
2017-05-30 15:55           ` Ludovic Courtès
2017-05-24 15:52 ` Brendan Tildesley
2017-05-27 10:04   ` Ludovic Courtès
2017-05-28 20:41     ` Maxim Cournoyer
2017-05-30 15:17       ` Ludovic Courtès
2017-06-03 21:16         ` Maxim Cournoyer
2017-05-24 16:09 ` Catonano
2017-05-24 16:25 ` Jan Nieuwenhuizen
2017-05-24 18:40   ` Adonay Felipe Nogueira
2017-05-24 19:34   ` Catonano
2017-05-24 19:56     ` Ricardo Wurmus
2017-05-30  0:09       ` myglc2
2017-05-24 21:47     ` Leo Famulari
2017-05-24 21:45   ` Leo Famulari
2017-05-25  8:11     ` What???s next? Pjotr Prins
2017-05-27 10:16       ` Ludovic Courtès
2017-05-28  7:30         ` What's next? Pjotr Prins
2017-05-28 20:48           ` Ludovic Courtès
2017-05-28 22:05             ` Roel Janssen
2017-05-30 15:19               ` Ludovic Courtès
2017-05-30 20:15                 ` Pjotr Prins
2017-05-29  2:31             ` Maxim Cournoyer
2017-05-28 20:37         ` What???s next? Maxim Cournoyer
2017-05-28 21:34           ` Ricardo Wurmus
2017-05-30 15:14           ` Ludovic Courtès
2017-05-25 14:57     ` What’s next? Chris Marusich
2017-05-25 18:32       ` Leo Famulari
2017-05-25 20:01       ` Ricardo Wurmus
2017-05-25 20:41         ` Adonay Felipe Nogueira
2017-05-27 10:13         ` Ludovic Courtès
2017-05-29 23:28           ` myglc2
2017-06-08 14:35           ` Ricardo Wurmus
2017-05-27 10:09   ` Ludovic Courtès
2017-10-04 15:12 ` Release! Ludovic Courtès
2017-10-05 19:18   ` Release! Christopher Baines
2017-10-06 13:01     ` Release! Ludovic Courtès
2017-10-09  7:25       ` Release! Christopher Baines
2017-10-09 16:25         ` Release! Ludovic Courtès
2017-10-06 18:30   ` Release! Ricardo Wurmus
2017-10-06 23:31     ` Release! David Pirotte
2017-10-07  9:18       ` Release! Hartmut Goebel
2017-10-07 12:21         ` Release! David Pirotte
2017-10-07 21:30       ` Release! Ricardo Wurmus
2017-10-08 13:08         ` Release! Hartmut Goebel
2017-10-07  4:06     ` Mark H Weaver [this message]
2017-10-07 19:35       ` [PATCH] DRAFT: build: Compile scheme modules in batches (was Re: Release!) Efraim Flashner
2017-10-08  9:19       ` Ricardo Wurmus
2017-10-08 12:03         ` Ricardo Wurmus
2017-10-08 13:26           ` Ricardo Wurmus
2017-10-09  7:38             ` Ludovic Courtès
2017-10-09 11:32               ` Ricardo Wurmus
2017-10-10  6:52                 ` Ricardo Wurmus
2017-10-09  7:42       ` Ludovic Courtès
2017-10-09  7:53     ` Release! Ludovic Courtès
2017-11-20 22:07     ` Release! Ludovic Courtès
2017-11-30 10:40     ` Release! Ludovic Courtès
2017-12-01  2:57       ` Release! Maxim Cournoyer
2017-12-01 18:30       ` Release! Leo Famulari
2017-12-01 19:32         ` Release! Ricardo Wurmus
2017-12-04  8:53           ` Release! Ludovic Courtès
2017-12-04  8:58           ` ISO image available for testing! Ludovic Courtès
2017-12-04 21:35             ` Christopher Baines
2017-12-04 22:34               ` Ludovic Courtès
2017-12-05 22:47               ` Ludovic Courtès
2017-12-06  0:52                 ` Mark H Weaver
2017-12-06  1:17                   ` Ben Woodcroft
2017-12-06  2:16                   ` native-inputs ending up as run-time references [was: ISO image available for testing!] Tobias Geerinckx-Rice
2017-12-06  3:18                     ` Leo Famulari
2017-12-06  3:48                       ` Tobias Geerinckx-Rice
2017-12-06  8:04                   ` ISO image available for testing! Mark H Weaver
2017-12-06  8:14                   ` Ludovic Courtès
2017-12-06 16:29                     ` Tobias Geerinckx-Rice
2017-12-07 20:09                 ` Christopher Baines
2017-12-07 21:19                   ` Ludovic Courtès
2017-12-04  8:52         ` Release! Ludovic Courtès
2017-12-05  2:47           ` Release! Maxim Cournoyer

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=87fuavzjms.fsf_-_@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.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).