lilypond-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]