-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
buildsystem: switch to dynamic scheduler #4092
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Drop Also, add a fix for a couple of simple add-ons that were breaking due to lack of 7za when being packaged before |
Squashed the latest commits. |
… handles failed jobs
cp (and potentially mkdir -p) are not atomic, and we have seen situations where two packages concurrently copying the same file (eg. the udev rule for xf86-video-nvidia and xf86-video-nvidia-legacy) will succeed for one package but the other package fails with a "file exists" error (as the file didn't exist when it checked, but does exist when it actually copies the file). Not even cp -f will avoid this issue. There are several workarounds, but the most practical (and general) solution is to ensure sequential updates of the image and shared sysroot directories.
HiassofT
approved these changes
Jan 20, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks to @dhewg for the initial work/prompting on this.
This PR moves us beyond the current "static plan" schedule which has it's limitations. Optimising the static plan can only take us so far, and due to the fairly "dumb" nature of
parallel
we're stuck with several limitations.Replacing
parallel
with something that is more knowledgeable about the LibreELEC build process and switching to a "dynamic" schedule optimises the remaining few minutes out of the static plan, while also allowing us to more efficiently implement in Python what we had previously had to support in shell code (ie. job failure handling) and eliminating recursive dependency stamp checking and subequent dependency building.With the dynamic scheduler it is no longer necessary to recursively
build
orinstall
package dependencies - the exception beinginitramfs:target
- which results in fewerunpack
locks and stamp checks. Having eliminated recursivebuild
andinstall
we now only need to acquire locks duringunpack
andreconf
- all other "locks" are purely for logging purposes.By default logs will continue to be "grouped" or "burst" as they are now. The output from each log will be sent to
stdout
by default, although output tostdout
can be disabled entirely (--log-combine never
) or output only on failure (--log-combine fail
), both of which may help reduce IO.Debugging can be enabled with
--debug
(MTDEBUG=yes
) with output written to${THREAD_CONTROL}/debug.log
.Verbose output can be enabled with
--verbose
(MTVERBOSE=yes
) with output written tostderr
.Completed job information can be written to
${THREAD_CONTROL}/joblog
if--joblog
is enabled (which it is, by default). The following space-delimited fields for each job will be written as each job is completed:DONE
,FAIL
)build
,install
)linux:target
)--log-burst
is enabled)Below are some before/after comparisons for Generic and RPi2 builds (
image
andall
addons)--burst --log-combine always
THREADCOUNT=4
/CONCURRENCY_MAKE_LEVEL=8
(ie.T4C8
), the second forT8C8
to demonstrate the difference when "over committing" resources-l
switch forninja
andmake
)Generic,
image
(T4C8
andT8C8
):Generic,
all
addons (T4C8
andT8C8
):RPi2,
image
(T4C8
andT8C8
):RPi2,
all
addons (T4C8
andT8C8
):