linux/poky.git/bitbake/lib/bb/runqueue.py, branch yocto-4.1.2

bitbake: runqueue: Fix race issues around hash equivalence and sstate reuse

2022-11-24T15:25:15+00:00

We identified a use case where a native recipe (autoconf-native) was rebuilt with no change in output yet the sstate for do_package tasks wasn't being used. The issue is that do_package tasks have a hard dependency on pseudo-native:do_populate_sysroot. That task was one of the many tasks being rehashed when autoconf-native's hash was changed. If update_tasks processed a recipe before it had processed pseudo-native, that recipe would be marked as not possible from sstate and would run the full tasks. The fix is to split the processing into two passes, first to handle the existing covered/notcovered updates, then in the second pass, check whether there are "harddep" issues. This defers the do_package tasks until after pseudo-native is installed from sstate as expected and everything works well again. (Bitbake rev: 3b2d1331487a74863e74cc0c5564004cbb1b5a4a) Signed-off-by: Richard Purdie (cherry picked from commit e479d1e418a7d34f0a4663b4a0e22bb11503c8ab) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: runqueue: Change pressure file warning to a note

2022-08-24T14:43:36+00:00

The user does need to be told about this but it isn't really a warning, just something they may need to be aware of. Drop the level accordingly. (Bitbake rev: 9bdedc8074990e613c9567e2cd8072f8d885f07f) Signed-off-by: Richard Purdie

bitbake: runqueue: add memory pressure regulation

2022-08-12T10:49:29+00:00

Prevent new tasks from being scheduled if the memory pressure is above a certain threshold, specified through the "BB_MAX_PRESSURE_MEMORY" variable in the conf/local.conf file. This is an extension to the following commit and hence regulates pressure in the same way: 48a6d84de1 bitbake: runqueue: add cpu/io pressure regulation Memory pressure is experienced when time is spent swapping, refaulting pages from the page cache or performing direct reclaim. This is why memory pressure is rarely seen but might be useful as a last resort to prevent OOM errors. (Bitbake rev: 44c395434c7be8dab968630a610c8807f512920c) Signed-off-by: Aryaman Gupta Signed-off-by: Randy Macleod Signed-off-by: Richard Purdie

bitbake: runqueue: Drop deadlock breaking force fail

2022-08-08T14:44:47+00:00

I'm 99% certain this failing of a scenequeue task corrupts runqueue and causes all kinds of breakage. I'd rather runqueue deadlocked than corrupted and did weird things so drop this code. We've seen builds where the deadlock triggers and it then tries to run tasks where the SQ task already ran with very confusing failures. It is likely it is this code causing it. (Bitbake rev: 8efced47fcb47851a370fd6786df6fb377f99963) Signed-off-by: Richard Purdie

bitbake: runqueue: Improve deadlock warning messages

2022-08-08T14:44:47+00:00

Tweak the deadlock breaking messages to be explict about which task is blocked on which other task. The messages currently imply it is "freeing" the blocking task which is confusing. (Bitbake rev: cf7f60b83adaded180f6717cb4681edc1d65b66d) Signed-off-by: Richard Purdie

bitbake: runqueue: Ensure deferred tasks are sorted by multiconfig

2022-08-08T14:44:47+00:00

We have to prefer one multiconfig over another when deferring tasks, else we'll have cross-linked build trees and nothing will be able to build. In the original population code, we sort like this but we don't after rehashing. Ensure we have the same sorting after rehashing toa void deadlocks. (Bitbake rev: 27228c7f026acb8ae9e1211d0486ffb7338123a2) Signed-off-by: Richard Purdie

bitbake: runqueue: add cpu/io pressure regulation

2022-07-28T10:55:06+00:00

Prevent the scheduler from starting new tasks if the current cpu or io pressure is above a certain threshold and there is at least one active task. This threshold can be specified through the "BB_PRESSURE_MAX_{CPU|IO}" variables in conf/local.conf. The threshold represents the difference in "total" pressure from the previous second. The pressure data is discussed in this oe-core commit: 061931520b buildstats.py: enable collection of /proc/pressure data where one can see that the average and "total" values are available. From tests, it was seen that while using the averaged data was somewhat useful, the latency in regulating builds was too high. By taking the difference between the current pressure and the pressure seen in the previous second, better regulation occurs. Using a shorter time period is appealing but due to fluctations in pressure, comparing the current pressure to 1 second ago achieves a reasonable compromise. One can look at the buildstats logs, that usually sample once per second, to decide a sensible threshold. If the thresholds aren't specified, pressure is not monitored and hence there is no impact on build times. Arbitary lower limit of 1.0 results in a fatal error to avoid extremely long builds. If the limits are higher than 1,000,000, then warnings are issued to inform users that the specified limit is very high and unlikely to result in any regulation. The current bitbake scheduling algorithm requires that at least one task be active. This means that if high pressure is seen, then new tasks will not be started and pressure will be checked only for as long as at least one task is active. When there are no active tasks, an additional task will be started and pressure checking resumed. This behaviour means that if an external source is causing the pressure to exceed the threshold, bitbake will continue to make some progress towards the requested target. This violates the intent of limiting pressure but, given the current scheduling algorithm as described above, there seems to be no other option. In the case where only one bitbake build is running, the implications of the scheduler requirement will likely result in pressure being higher than the threshold. More work would be required to ensure that the pressure threshold is never exceeded, for example by adding pressure monitoring to make and ninja. (Bitbake rev: 502e05cbe67fb7a0e804dcc2cc0764a2e05c014f) Signed-off-by: Aryaman Gupta Signed-off-by: Randy Macleod Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

bitbake: runqueue: Fix unihash cache mismatch issues

2022-06-02T11:28:21+00:00

Very occasionally we see errors in eSDK testing on the autobuilder where the task hashes in the eSDK don't match what was just built. I was able to inspect one of these build directories and noticed that the bb_unihashes.dat file in the eSDK was zero sized. Whilst inspecting the code to understand the cause, I noticed that updated hashes are not saved out in subsequent updates of the values in the rehash process. Add a missing sync call to ensure this happens. (Bitbake rev: 7912dabbcf444a3c3d971cca4a944a8b931e301b) Signed-off-by: Richard Purdie

bitbake: runqueue: Fix sig file location when using multiconfig

2022-04-30T06:33:52+00:00

We're using the wrong data store when trying to locate siginfo files, fix this. Thanks to Gregory Lumen for spotting. [YOCTO #14774] (Bitbake rev: 0ed800e19a3197f8e622c8d3b630aae384e60aba) Signed-off-by: Richard Purdie

bitbake: runqueue: Drop pointless variable assignment

2022-04-21T20:00:35+00:00

This is set at the start of the loop anyway so it does nothing. Drop the pointless code. (Bitbake rev: e6a3173c9cdf349ccbd4cf612868f92cce8717c8) Signed-off-by: Richard Purdie