linux/poky.git/bitbake, branch yocto-4.0.15

bitbake: runqueue: show number of currently running bitbake threads when pressure changes

2023-12-11T16:13:49+00:00

* it might be a bit confusing as it shows number of threads before making the decision to start more tasks and also it can show only a few tasks running, but not because of pressure when there just aren't many tasks left or wait for their dependencies to be finished first * example output: NOTE: Pressure status changed to CPU: True, IO: None, Mem: None (CPU: 297589.5/200000.0, IO: 5522.2/None, Mem: 779.2/None) - using 7/8 bitbake threads NOTE: Pressure status changed to CPU: False, IO: None, Mem: None (CPU: 196381.2/200000.0, IO: 2667.9/None, Mem: 556.2/None) - using 2/8 bitbake threads (Bitbake rev: 42a1c9fe698a03feb34c5bba223c6e6e0350925b) Signed-off-by: Martin Jansa Signed-off-by: Steve Sakoman

bitbake: runqueue: show more pressure data

2023-12-11T16:13:49+00:00

* with latest bitbake I'm seeing very low number of bitbake tasks executed in parallel, probably due to pressure regulation show the values this is based on in the note * also simplify a bit by counting the pressure and exceeds signs only once (Bitbake rev: 1050145c3004861ebede4777fd4fbd89d0470716) Signed-off-by: Martin Jansa Signed-off-by: Steve Sakoman

bitbake: runqueue.py: fix PSI check logic

2023-12-11T16:13:49+00:00

The current calculation is not correct because if tdiff is less than 1.0, it's not taken into consideration when calculating the current pressure. Also, make it clear that the 1.0s is the psi accumulation cycle, which might be changed in the future. We have this cycle because it could largely avoid the 0 result issue, that is, if the interval between checks are too small, the result might be 0. With this accumulation logic, which has been there but let's make it clear, this 0 result problem could be mitigated. (Bitbake rev: 76889ff0a8938a3d77603d2af176aa9e264df839) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: Add pressure change logging

2023-12-11T16:13:49+00:00

It is currently hard to tell when bitbake is throttling task execution due to system pressure changes. Add notes to the console output to make this clearer, only generating output when the values change. (Bitbake rev: b5f77e8159ad321f31999af8304f082a2c56b537) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: fix PSI check calculation

2023-12-11T16:13:49+00:00

The current PSI check calculation does not take into consideration the possibility of the time interval between last check and current check being much larger than 1s. In fact, the current behavior does not match what the manual says about BB_PRESSURE_MAX_XXX, even if the value is set to upper limit, 1000000, we still get many blocks on new task launch. The difference between 'total' should be divided by the time interval if it's larger than 1s. (Bitbake rev: 2b2997ab6bdda730e4b638f416311a73e0c42156) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: Fix disk space monitoring on cephfs

2023-11-09T14:41:17+00:00

Error occured while running bitbake on cephfs: WARNING: The free inode of path is running low (-0.001K left) ERROR: Immediately halt since the disk space monitor action is "HALT"! (Bitbake rev: a7f6c3e67bd9170e93b2b94676e84018faf0df91) Signed-off-by: Samantha Jalabert Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: convert deferral messages from bb.note to bb.debug

2023-11-09T14:41:17+00:00

Using multiconfig to target baremetal pieces of the system and building corresponding toolchains for them results in hundreds and hundreds of "Deferring %s after %s" and "Deferred task %s now buildable". To clean up the output and to reduce risk of missing important warnings, convert these notice messages to debug messages. (Bitbake rev: 3505d8d8c02b041946670ab6bc5751e54fe292ff) Signed-off-by: Denys Dmytriyenko Signed-off-by: Denys Dmytriyenko Signed-off-by: Richard Purdie (cherry picked from commit 64bc00a46d1aacc23fe7e8d9a46a126f3a4bc318) Signed-off-by: Steve Sakoman

bitbake: tinfoil: Do not fail when logging is disabled and full config is used

2023-11-09T14:41:17+00:00

If Tinfoil is initialized with setup_logging = False and Tinfoil.prepare() is called with config_only = False, then it fails because self.localhandlers is only initialized when setup_logging = True. This is seen with, e.g., `bitbake-getvar -q -r busybox MACHINE`: Traceback (most recent call last): File ".../bitbake/bin/bitbake-getvar", line 41, in tinfoil.prepare(quiet=2) File ".../bitbake/lib/bb/tinfoil.py", line 390, in prepare for handler in self.localhandlers: AttributeError: 'Tinfoil' object has no attribute 'localhandlers'. Did you mean: 'oldhandlers'? (Bitbake rev: e452c6d7ba5bb4f78a1d2bfb742794efdf171dbc) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie (cherry picked from commit 616101ddb630e2c9975022068b52a87c4cf647f6) Signed-off-by: Steve Sakoman

bitbake: bitbake-getvar: Make --quiet work with --recipe

2023-11-09T14:41:17+00:00

Initializing Tinfoil with setup_logging = False only has an effect when recipe parsing is not needed. To make it work regardless of if --recipe is used, manipulate the quiet parameter to Tinfoil.prepare() instead. (Bitbake rev: 161ab0d5bab74732e12d490cee50e14295be0a9f) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie (cherry picked from commit 71ee69a20f21f3d37f4f060a7d8e87d9f1dc6aa1) Signed-off-by: Steve Sakoman

bitbake: SECURITY.md: add file

2023-10-24T15:28:15+00:00

Add a SECURITY.md file with hints for security researchers and other parties who might report potential security vulnerabilities. (Bitbake rev: 6c1ffa9091d0c53a100e8c8c15122d28642034bd) Signed-off-by: Marta Rybczynska Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman