aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
diff options
context:
space:
mode:
authorStijn Tintel <stijn@linux-ipv6.be>2022-02-19 17:54:22 +0200
committerDaniel Golle <daniel@makrotopia.org>2022-04-06 14:03:58 +0100
commit82e1f041f9a6cf9232c9f73938ef3b11c34cca0f (patch)
tree66312fc75418997996ece990b737ccdf6bd49bd7 /README.md
parentec2bc81c78585755491f9a1a3f30edb6312025f0 (diff)
downloadupstream-82e1f041f9a6cf9232c9f73938ef3b11c34cca0f.tar.gz
upstream-82e1f041f9a6cf9232c9f73938ef3b11c34cca0f.tar.bz2
upstream-82e1f041f9a6cf9232c9f73938ef3b11c34cca0f.zip
image: let mksquashfs4 use all processors
Drop the -processors argument from the mksquashfs4 call, so it will use all available processors. This dramatically reduces the time to create squashfs filesystems. The times below are observed when building an image for my main router, the WatchGuard Firebox M300 (qoriq target): Before: real 4m45,973s After: real 0m23,497s With this commit `mksquashfs` may use more cores than defined via `-j`. This is the same behaviour as for archive creation of ImageBuilder, SDK or toolchain. There is no trivial way to limit `mksquashfs` CPU core usage to the amount of "free" make jobs since two running `mksquashfs` instances would each run with the total allowed number (-j) of threads. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> [extended reasoning in commit message] Signed-off-by: Paul Spooren <mail@aparcar.org> (cherry picked from commit df2ae8826ced4f374bcb693b44d8a113ad150d70)
Diffstat (limited to 'README.md')
0 files changed, 0 insertions, 0 deletions