From: Tejun Heo <tj@kernel.org>
To: Henry Huang <henry.hj@antgroup.com>
Cc: changwoo@igalia.com, arighi@nvidia.com, void@manifault.com,
谈鉴锋 <henry.tjf@antgroup.com>,
"Yan Yan(cailing)" <yanyan.yan@antgroup.com>,
linux-kernel@vger.kernel.org, sched-ext@lists.linux.dev
Subject: Re: [PATCH v3] sched_ext: Implement SCX_OPS_TRACK_MIGRATION
Date: Mon, 23 Jun 2025 07:59:54 -1000 [thread overview]
Message-ID: <aFmWGi8n1ndB1K_M@slm.duckdns.org> (raw)
In-Reply-To: <20250623063033.76808-2-henry.hj@antgroup.com>
Hello,
On Mon, Jun 23, 2025 at 02:30:33PM +0800, Henry Huang wrote:
> For some BPF-schedulers, they should do something when
> task is doing migration, such as updating per-cpu map.
> If SCX_OPS_TRACK_MIGRATION is set, runnable/quiescent
> would be called whether task is doing migration or not.
It's rather odd to invoke runnable/quiescent on these transitions as the
runnable state isn't actually changing and the events end up triggering for
all the migration operations that SCX does internally.
In the head message (BTW, if it's just a single patch, it'd be better to
include all the context in the patch description), you said that this is
needed to udpate percpu data structures when tasks migrate. Wouldn't you be
able to do that by tracking whether the current CPU is different from the
previous one from ops.running()?
Thanks.
--
tejun
next prev parent reply other threads:[~2025-06-23 17:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 6:30 [PATCH v3] Implement SCX_OPS_TRACK_MIGRATION Henry Huang
2025-06-23 6:30 ` [PATCH v3] sched_ext: " Henry Huang
2025-06-23 6:42 ` Andrea Righi
2025-06-23 17:59 ` Tejun Heo [this message]
2025-06-24 3:03 ` [PATCH v3] sched_ext: include SCX_OPS_TRACK_MIGRATION Henry Huang
2025-06-25 23:07 ` Tejun Heo
2025-06-27 3:43 ` [PATCH v3] sched_ext: Implement SCX_OPS_TRACK_MIGRATION Henry Huang
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=aFmWGi8n1ndB1K_M@slm.duckdns.org \
--to=tj@kernel.org \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=henry.hj@antgroup.com \
--cc=henry.tjf@antgroup.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--cc=void@manifault.com \
--cc=yanyan.yan@antgroup.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.