Bug 15111

Additional info like reasonable sane defaults for hardware an average hobbyist person might have in 2023.  Obviously error on the low side of things, since one wouldn't be looking for these settings unless they are suffering swap-death or OOM kill.

Maybe also add them to the autogenerated conf/local.conf template like "make -j" settings and threads - commented out but there ready and easily deployed.

Bulk move of 5.1 M4 to 5.2 M2 as approved by AlexB.

Hello,

This seems to have been done with following commit from Michael:
https://git.openembedded.org/bitbake/commit/?id=72e9847dd578c3cbed52a9c16fea23ebbeef5046

Can you confirm/deny? So I can update the bug status accordingly.

Thanks,
Antonin

The addition helps, but still it seems what is there is a rather clinical description of the variable.  And maybe that is what we want in the section that documents all the variables.

What is missing is the "How do I effectively use this?"

For example, I found out (by trial and error) that I had to start with values more like 25k just to even get in the ballpark.  Makes the example value of 500 seem wrong, or seem like the user is doing something wrong?

And where does it say that the console will output state changes with true/false status for each metric (CPU, i/o, ...) so that a person can adjust/tune their initial starting point?

And do they have to ^C the build and manually hack the config file every time they want to tweak and hone in on a good value?  That seems super klunky and tedious - esp. if the example value is way off.   Or can it be done on the fly from the build console?

And once satisfactory values are reached, how does one turn off the pressure state change messages - as they overwhelm the build console otherwise.

The feature might be awesome, but if people aren't guided how to use it effectively, it might as well not exist outside of the sphere of AutoBuilder folks.

Bulk move of bugs I am assigned to from Milestone 5.2M4 to 5.3M1.

(In reply to Paul Gortmaker from comment #4)
> The addition helps, but still it seems what is there is a rather clinical
> description of the variable.  And maybe that is what we want in the section
> that documents all the variables.
> 
> What is missing is the "How do I effectively use this?"
> 
> For example, I found out (by trial and error) that I had to start with
> values more like 25k just to even get in the ballpark.  Makes the example
> value of 500 seem wrong, or seem like the user is doing something wrong?
> 
> And where does it say that the console will output state changes with
> true/false status for each metric (CPU, i/o, ...) so that a person can
> adjust/tune their initial starting point?
> 
> And do they have to ^C the build and manually hack the config file every
> time they want to tweak and hone in on a good value?  That seems super
> klunky and tedious - esp. if the example value is way off.   Or can it be
> done on the fly from the build console?
> 
> And once satisfactory values are reached, how does one turn off the pressure
> state change messages - as they overwhelm the build console otherwise.
> 
> The feature might be awesome, but if people aren't guided how to use it
> effectively, it might as well not exist outside of the sphere of AutoBuilder
> folks.

Hi Paul,

Here's my take on trying to summarize how one can limit the resources used on the host:
https://lore.kernel.org/r/20250624-resource-limiting-v1-1-f8f5edbdaf03@bootlin.com

For the BB_PRESSURE variables specifically, I found that setting a low value first and then gradually increasing the value using the information printed on the console is helpful - I wouldn't know of any other way to do it for now.

Antonin

The following commit is now in master: https://git.yoctoproject.org/yocto-docs/commit/?id=584b8b30cd884ff6c62efcff9e9b566476a84589

This is a first document to gather information on how to limit the resources used by the host, include pressure information.

I'm closing this bug as it includes more in-depth explanation on BB_PRESSURE variables.