All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antonin Godard" <antonin.godard@bootlin.com>
To: "Richard Purdie" <richard.purdie@linuxfoundation.org>,
	<bitbake-devel@lists.openembedded.org>
Cc: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [bitbake-devel] [PATCH] runqueue: show the current pressure as debug messages
Date: Wed, 02 Jul 2025 08:21:54 +0200	[thread overview]
Message-ID: <DB1CPMFTBKOK.1B0C9LPTCQK1B@bootlin.com> (raw)
In-Reply-To: <e0ec39370f30659958447e6a5def8d88d3dc4649.camel@linuxfoundation.org>

On Tue Jul 1, 2025 at 11:23 PM CEST, Richard Purdie wrote:
> On Tue, 2025-07-01 at 11:53 +0200, Antonin Godard via lists.openembedded.org wrote:
>> The current pressure logic only prints pressure information when the
>> limits set by BB_PRESSURE_* variables are exceeded. But in order to
>> determine the best pressure limits for a given host, it can be useful to
>> monitor pressure information after setting BB_PRESSURE_* to the maximum
>> (1000000) and get a sense of how high the pressure can be.
>> 
>> Add three bb.debug() calls showing that information.
>> 
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>  lib/bb/runqueue.py | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/lib/bb/runqueue.py b/lib/bb/runqueue.py
>> index 80f3d3282f..cae4bfa3e5 100644
>> --- a/lib/bb/runqueue.py
>> +++ b/lib/bb/runqueue.py
>> @@ -206,6 +206,9 @@ class RunQueueScheduler(object):
>>                  cpu_pressure = (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) / tdiff
>>                  io_pressure = (float(curr_io_pressure) - float(self.prev_io_pressure)) / tdiff
>>                  memory_pressure = (float(curr_memory_pressure) - float(self.prev_memory_pressure)) / tdiff
>> +                bb.debug(3, f"Current CPU pressure: {cpu_pressure}")
>> +                bb.debug(3, f"Current IO pressure: {io_pressure}")
>> +                bb.debug(3, f"Current Memory pressure: {memory_pressure}")
>>                  exceeds_cpu_pressure =  self.rq.max_cpu_pressure and cpu_pressure > self.rq.max_cpu_pressure
>>                  exceeds_io_pressure =  self.rq.max_io_pressure and io_pressure > self.rq.max_io_pressure
>>                  exceeds_memory_pressure =  self.rq.max_memory_pressure and memory_pressure > self.rq.max_memory_pressure
>> 
>
> I'm torn on this, debug messages aren't without their overhead even if
> not printed. How often do these end up outputted? If nothing else there
> should be one bb.debug call and not 3...

Actually, quite a lot, so I should reduce this to one call, or find out a way to
reduce the amount of messages printed.

Thanks,
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



  reply	other threads:[~2025-07-02  6:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01  9:53 [PATCH] runqueue: show the current pressure as debug messages Antonin Godard
2025-07-01 21:23 ` [bitbake-devel] " Richard Purdie
2025-07-02  6:21   ` Antonin Godard [this message]
2025-07-14 10:48     ` Quentin Schulz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB1CPMFTBKOK.1B0C9LPTCQK1B@bootlin.com \
    --to=antonin.godard@bootlin.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.