[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by addr
From: |
David Kastrup |
Subject: |
Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by address@hidden) |
Date: |
Sat, 07 Mar 2020 16:30:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
address@hidden writes:
> On 2020/03/07 12:39:31, dak wrote:
>>
>> Harm has a system with memory pressure. That means that he so far has
>> only been able to work with
>>
>> CPU_COUNT=2 make -j2 doc
>
> Well,
> CPU_COUNT=3 make -j3 doc
> is mostly no problem
Ok.
>> Since now lilypond-doc is no longer serialised, he'd need to reduce to
>>
>> CPU_COUNT=1 make -j2 doc
>>
>> or
>>
>> CPU_COUNT=2 make -j1 doc
>
> Let me check, putting this patch on top of current master, right?
> With guile-1 or guile-2?
I'd use Guile-1, for the reason that it runs faster, eats less memory,
and is more repeatable by virtue of not crashing.
> I've little time atm, thus I'm not sure when I'm able to start
> testings...
The way this works is that running of lilypond-book in one directory
blocks running lilypond-book in other directories but nothing else. So
you can up, using CPU_COUNT=3 make -j3 with one job of lilypond-book
that starts up 3 copies of LilyPond for large workloads, as well as with
3 jobs in other directories. Once those jobs actually run into
lilypond-book, they are stalled within lilypond-book without starting
LilyPond processes until the first lilypond-book has finished.
So the worst memory use is for when one copy of lilypond-book has
finished with its LilyPond part and starts the EPS and PDF processing,
another copy of lilypond-book takes over and starts its LilyPond
processes, and something else happens in another directory.
--
David Kastrup