From: Ingo Molnar <mingo@kernel.org>
To: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: peterz@infradead.org, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, qyousef@layalina.io,
linux-kernel@vger.kernel.org, vschneid@redhat.com,
joshdon@google.com, riel@surriel.com
Subject: Re: [PATCH] sched/fair: Simplify continue_balancing for newidle
Date: Tue, 26 Mar 2024 09:07:58 +0100 [thread overview]
Message-ID: <ZgKCXrUbBIxp6+mu@gmail.com> (raw)
In-Reply-To: <20240325153926.274284-1-sshegde@linux.ibm.com>
* Shrikanth Hegde <sshegde@linux.ibm.com> wrote:
> newidle(CPU_NEWLY_IDLE) balancing doesn't stop the load balancing if the
> continue_balancing flag is reset. Other two balancing (IDLE, BUSY) do
> that. newidle balance stops the load balancing if rq has a task or there
> is wakeup pending. The same checks are present in should_we_balance for
> newidle. Hence use the return value and simplify continue_balancing
> mechanism for newidle. Update the comment surrounding it as well.
Assuming there are no side-effects to balancing behavior.
> No change in functionality intended.
Is this actually true? Any change to behavior invalidates such a sentence.
> /*
> + * We must set idle_stamp _before_ calling sched_balance_rq()
> + * for CPU_NEWLY_IDLE, such that we measure the this duration
> + * as idle time.
> */
'the this' ...?
Thanks,
Ingo
next prev parent reply other threads:[~2024-03-26 8:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 15:39 [PATCH] sched/fair: Simplify continue_balancing for newidle Shrikanth Hegde
2024-03-26 8:07 ` Ingo Molnar [this message]
2024-03-26 9:00 ` Shrikanth Hegde
2024-03-26 15:11 ` Dietmar Eggemann
2024-03-26 19:15 ` Ingo Molnar
2024-03-26 19:24 ` [tip: sched/core] sched/fair: Simplify the continue_balancing logic in sched_balance_newidle() tip-bot2 for Shrikanth Hegde
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=ZgKCXrUbBIxp6+mu@gmail.com \
--to=mingo@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=joshdon@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=riel@surriel.com \
--cc=sshegde@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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.