Ken Moffat via blfs-book wrote:
On Sun, Oct 08, 2017 at 02:28:28AM -0000, via blfs-book wrote:
Author: dj
Date: Sat Oct 7 19:28:28 2017
New Revision: 19304
Log:
Fix SBU value (ninja -j1) for systemd.
The last time I looked at ninja, it used the number of cores plus 2
(-j3 on single processor, -j6 on 4 cores). There is merit in
documenting a -j1 time for a package which builds quickly, but
(unless things have changed a lot) the book's instructions will use
something more than one processor (e.g. watch 'top' and count the
percentages - I think they will show a total percentage approaching
100 * number of cores.
If I'm right, this might be one package where using the value for a
machine with 4 CPUs (as a commonly-available base) even for a quick
package might be worthwhile - we normally only force -j1 where we
have to becuase of broken Makefiles.
My interest in this is that I'm thinking about extending the
Editors' Guide to include details of reducing the number of
processors available (taksset) when building on machines with many
cores.
I agree that 4 cores are commonly available. Using -j1 is reasonable for
consistency. More than -j4 is not (normally). As long as we document the
number of cores used using higher levels of parallelism I think it is OK,
but the default should still be 1.
My rule of thumb is that if the package takes less than 0.5 SBU at -j1,
then I don't use higher levels.
I note that we use -j8 in two places: libreoffice (still 41 SBU) and gimp
help (only if building all languages).
-- Bruce
P.S. I really don't like ninja using all processors. In the case of my
laptop (i7 processor), a long-ish build (e.g. gcc) results in very high
temperatures. That package needs to introduce an environment variable to
limit the number of cores instead of insisting on a command line entry.
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
