public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Smith <paul@mad-scientist.net>
To: Fiodar Stryzhniou <fedor_qd@mail.ru>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Out of memory while building GCC 12.1.0
Date: Fri, 10 Jun 2022 10:42:03 -0400	[thread overview]
Message-ID: <5dc1d2854640baba900b3889bd0d75bea7187d54.camel@mad-scientist.net> (raw)
In-Reply-To: <b5d6a251-0c1e-594a-a6d9-855762b6e9bc@mail.ru>

On Fri, 2022-06-10 at 15:29 +0300, Fiodar Stryzhniou wrote:
> > If you don't set that variable it will try to compile every file at
> > once. Either set the variable, or fix your script to use a sensible
> > default like -j"${NUMBER_OF_PROCESSORS:-1}"
> 
> Looks like you right. Harcoded to -j6 helps.

Another way to go is to add the "-l" option.  This is often combined
with "-j" (no limit) to have your build limited by load rather than by
job count.

So if you want the load on your system to be no greater than 2, you can
say "-j -l2".

Just to be aware, on Linux a load of "1" means approximately "1 CPU is
100% busy".  So if you use "-l2" then you'll likely have between 2 and
3 jobs running, but if your jobs have to do a lot of waiting (say they
need to do a lot of disk IO / your disk is slow) then you will have
more running.

Anyway, getting the best behavior out of parallelism is a matter of
trial and error and is specific to your build environment.  But plain
"-j" with no other control is virtually never a good idea :).

  parent reply	other threads:[~2022-06-10 14:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 11:55 Fiodar Stryzhniou
2022-06-10 12:14 ` Xi Ruoyao
2022-06-10 12:18   ` Jonathan Wakely
2022-06-10 12:29     ` Fiodar Stryzhniou
2022-06-10 12:42       ` Jonathan Wakely
2022-06-10 15:06         ` Fiodar Stryzhniou
2022-06-10 14:42       ` Paul Smith [this message]
2022-06-10 15:56         ` Segher Boessenkool
2022-06-10 17:04           ` Fiodar Stryzhniou
2022-06-10 17:09           ` Paul Smith
2022-06-10 17:15             ` Segher Boessenkool

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

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

  git send-email \
    --in-reply-to=5dc1d2854640baba900b3889bd0d75bea7187d54.camel@mad-scientist.net \
    --to=paul@mad-scientist.net \
    --cc=fedor_qd@mail.ru \
    --cc=gcc-help@gcc.gnu.org \
    /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.
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).