All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Kuba Piecuch <jpiecuch@google.com>,
	David Vernet <void@manifault.com>,
	Andrea Righi <arighi@nvidia.com>,
	Changwoo Min <changwoo@igalia.com>,
	sched-ext@lists.linux.dev
Cc: Emil Tsalapatis <emil@etsalapatis.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()
Date: Mon, 29 Jun 2026 09:42:45 -1000	[thread overview]
Message-ID: <90443ebc5ac832365031c7d569206fcf@kernel.org> (raw)
In-Reply-To: <DJI17L7ZP0BT.3VW1FVZMRGWOM@google.com>

Hello, Kuba.

On Thu, Jun 25, 2026 at 09:45:30AM +0000, Kuba Piecuch wrote:
> Nit: balance_one() doesn't happen in balance() anymore, it happens in pick.
> So IMO it should read "... skips pick_task_scx() for the CPU, ...".

Right, fixed in v2.

> Is there a more precise check that we could do to determine if this switch is
> due to core-sched forcing the CPU idle? I was thinking about
> rq->core->core_forceidle_count, but IIUC that's the core-wide number of CPUs
> forced idle, so it's not a reliable signal about any particular CPU.

I couldn't find anything with better granularity either, so v2 keeps the
sched_core_enabled() gate.

> I wasn't able to quickly convince myself that an IMMED task will be reenqueued
> in the case where a CPU running an SCX task has an IMMED task enqueued in its
> local DSQ by a remote CPU, and the CPU is forced idle while the IMMED task
> is on the local DSQ.
> Looks like we might need a call to schedule_reenq_local() somewhere in here
> (in a separate patch, of course). WDYT?

Makes sense, and not too surprising. For now maybe we just note it in the
comment.

Thanks.

-- 
tejun

  reply	other threads:[~2026-06-29 19:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 23:55 [PATCH] sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() Tejun Heo
2026-06-25  9:45 ` Kuba Piecuch
2026-06-29 19:42   ` Tejun Heo [this message]
2026-06-29 19:43 ` [PATCH v2] " Tejun Heo
2026-06-29 20:06   ` Andrea Righi

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=90443ebc5ac832365031c7d569206fcf@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=emil@etsalapatis.com \
    --cc=jpiecuch@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=void@manifault.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.