From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: Neil Horman <nhorman@redhat.com>,
Neil Horman <nhorman@tuxdriver.com>,
dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>
Subject: Re: [PATCH] validate_abi: build faster by augmenting make with job count
Date: Wed, 20 Jul 2016 22:15:28 +0200 [thread overview]
Message-ID: <7923871.JAtBDztydg@xps13> (raw)
In-Reply-To: <CDB4778C-5EF7-4728-A77D-229F76A13225@intel.com>
2016-07-20 19:47, Wiles, Keith:
> On Jul 20, 2016, at 12:48 PM, Neil Horman <nhorman@redhat.com> wrote:
> > On Wed, Jul 20, 2016 at 07:40:49PM +0200, Thomas Monjalon wrote:
> >> 2016-07-20 13:09, Neil Horman:
> >>> From: Neil Horman <nhorman@redhat.com>
> >>> +if [ -z "$MAKE_JOBS" ]
> >>> +then
> >>> + # This counts the number of cpus on the system
> >>> + MAKE_JOBS=`lscpu -p=cpu | grep -v "#" | wc -l`
> >>> +fi
> >>
> >> Is lscpu common enough?
> >>
> > I'm not sure how to answer that. lscpu is part of the util-linux package, which
> > is part of any base install. Theres a variant for BSD, but I'm not sure how
> > common it is there.
> > Neil
> >
> >> Another acceptable default would be just "-j" without any number.
> >> It would make the number of jobs unlimited.
>
> I think the best is just use -j as it tries to use the correct number of jobs based on the number of cores, right?
No Keith, -j alone use as much jobs as it can create, i.e. much more than
the number of CPUs.
I have no measure but I remember it is less efficient than giving a number
based on available CPUs (with a multiply factor to avoid idling between jobs).
For a default value, both approaches are fine.
next prev parent reply other threads:[~2016-07-20 20:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 17:09 [PATCH] validate_abi: build faster by augmenting make with job count Neil Horman
2016-07-20 17:40 ` Thomas Monjalon
2016-07-20 17:48 ` Neil Horman
2016-07-20 19:47 ` Wiles, Keith
2016-07-20 20:15 ` Thomas Monjalon [this message]
2016-07-20 20:16 ` Neil Horman
2016-07-20 22:32 ` Wiles, Keith
2016-07-21 13:54 ` Neil Horman
2016-07-21 14:09 ` Wiles, Keith
2016-07-21 15:06 ` Neil Horman
2016-07-21 15:22 ` Wiles, Keith
2016-07-21 18:34 ` Neil Horman
2016-07-24 18:08 ` Wiles, Keith
2016-08-01 11:49 ` Neil Horman
2016-08-01 16:16 ` Wiles, Keith
2016-08-01 18:08 ` Neil Horman
2016-07-20 19:02 ` [PATCH v2] " Neil Horman
2016-07-22 10:46 ` Thomas Monjalon
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=7923871.JAtBDztydg@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=keith.wiles@intel.com \
--cc=nhorman@redhat.com \
--cc=nhorman@tuxdriver.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.