Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC v4 00/16]  Add per-package staging feature
Date: Sun, 28 Jun 2015 22:46:22 +0200	[thread overview]
Message-ID: <20150628204622.GE3950@free.fr> (raw)
In-Reply-To: <1435520570-20332-1-git-send-email-fabio.porcedda@gmail.com>

Fabio, All,

On 2015-06-28 21:42 +0200, Fabio Porcedda spake thusly:
> this patch set aims to improve build reproducibility by using a
> per-package staging directory.
> Also this feature aims to enable the top-level parallel make.

I haven't yet had time to look in the different patches, but I have a
preliminary comment about your benchmarks:

[--SNIP--]
> HW-MED:
> CPU: Intel i7-4790K (4x2 @4GHz) = 8 threads
> RAM: 16GB
> SSD: 512GB
> 
> HW-HIGH:
> CPU: 2 x Xeon 2620v3 (6x2 @2.40Ghz) = 24 threads
> RAM: 32GB
> SATA: RAID0 2x2TB 3.5" 7200rpm
> 1366
> 
> Test about output using hard links or note using the "defconfig-full"
> on HW-MED:
> 
> |  35GB |  99m | master branch
> |  37GB | 100m | patch set             
> | 153GB | 105m | patch set using hard links only for the toolchain sysroot
> | 225GB | 106m | patch set not using hardlinks at all
> 
> Test about performances of this patch set vs master branch:
> | 199m | HW-MED | defconfig-full | master branch | no top-level make |
> |  99m | HW-MED | defconfig-full | master branch | top-level make    | 
> | 100m | HW-MED | defconfig-full | patch set     | top-level make    |
> 
> | 350m | HW-HIGH | defconfig-full | master branch | no top-level make |
> |  73m | HW-HIGH | defconfig-full | master branch | top-level make    | 
> |  77m | HW-HIGH | defconfig-full | patch set     | top-level make    |
> 
> | 10m | HW-MED | defconfig-small | master branch | no top-level make |
> |  5m | HW-MED | defconfig-small | master branch | top-level make    | 
> |  5m | HW-MED | defconfig-samll | patch set     | top-level make    |
> 
> | 21m18s | HW-HIGH | defconfig-small | master branch | no top-level make |
> |  7m53s | HW-HIGH | defconfig-small | master branch | top-level make    | 
> |  7m54s | HW-HIGH | defconfig-samll | patch set     | top-level make    |

OK, so those benchmarks show that:

  - HDD are terribly slow when compared to SSDs

  - the build-time sppedup of parallel builds is huge, up to 4.5 on
    HW-HIGH, but mostly around 2 when HDDs do not play in the equation
    (i.e. on SSDs, or with all cached in RAM (small config)).

  - the build-time overhead is low, 5% in the worst case (73min -> 77min)

  - the size overhead is huge, a factor 4.4 with hardlinks, 6.5 without
    hardlinks

  - we're missing the benchmarks for this patchset without top-level
    parallel make (especially for the size overhead). Unless it no
    longer makes sense?

So, I'm really a bit skeptical. About five time the size for only about
twice the speedup, is it worth it? Sure some people will easily favour
speed over anything else, still the size overhead is really huge.

But I still think the idea is worth investigating.

Otherwise, I have a 2x4 core Xeon @3.4GHz with three SSDs in RAID0 which
might be better as a HW_HIGH system. I can spin a test-build with this
patchset on this machine to see what we get...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  parent reply	other threads:[~2015-06-28 20:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-28 19:42 [Buildroot] [RFC v4 00/16] Add per-package staging feature Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 01/16] packages: use TARGET_MAKE_ENV to add pps support Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 02/16] packages: for staging stuff use backtick instead of the shell function Fabio Porcedda
2015-07-12 14:39   ` Arnout Vandecappelle
2015-06-28 19:42 ` [Buildroot] [RFC v4 03/16] packages/scons: make avaiable the GCC_SYSROOT environment variable Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 04/16] packages/qt: read spec files from the per-package staging directory Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 05/16] pkg-perl: use TARGET_MAKE_ENV to add pps support Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 06/16] tooclahin-external: add support for GCC_SYSROOT Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 07/16] toolchain-external: move some code in a new function Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 08/16] toolchain-external: use the wrapper even for the linker "ld" Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 09/16] infra: add GCC_SYSROOT environment variable to support pps feature Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 10/16] pkg-cmake: " Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 11/16] pkg-python: add GCC_SYSROOT variable to add pps support Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 12/16] pacakge/luarocks: add GCC_SYSROOT environment variable to support pps Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 13/16] package/pkgconf: use GCC_SYSROOT to support pps feature Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 14/16] Makefile: add STAGINGNOPKG_DIR variable Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 15/16] pkg-generic: ADD_TOOLCHAIN_DEPENDENCY is true only for target packages Fabio Porcedda
2015-06-28 19:42 ` [Buildroot] [RFC v4 16/16] infra: add per-package staging feature Fabio Porcedda
2015-07-11 22:56   ` Romain Naour
2015-07-13  9:42     ` Fabio Porcedda
2015-06-28 19:53 ` [Buildroot] [RFC v4 00/16] Add " Fabio Porcedda
2015-06-28 20:34 ` Thomas Petazzoni
2015-06-28 20:46 ` Yann E. MORIN [this message]
2015-06-28 20:49   ` Yann E. MORIN
2015-06-28 20:57     ` Thomas Petazzoni
2015-06-28 21:04       ` Yann E. MORIN
2015-06-28 21:00   ` Thomas Petazzoni
2015-06-28 21:25     ` Yann E. MORIN
2015-06-29  8:35       ` Fabio Porcedda
2015-06-29 17:27         ` Yann E. MORIN
2015-06-29  8:38     ` Fabio Porcedda
2015-07-05  8:51 ` Fabio Porcedda
2015-07-05  9:01   ` Thomas Petazzoni
2015-07-05  9:26     ` Fabio Porcedda
2015-10-04 17:21 ` Arnout Vandecappelle
2015-10-04 17:51   ` Bjørn Forsman
2015-10-05 21:13   ` Fabio Porcedda

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=20150628204622.GE3950@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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