From: Hongyan Xia <hongyan.xia@transsion.com>
To: Valentin Schneider <vschneid@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Jiazi Li <jiazi.li@transsion.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] sched: Convert last bits of deprecated static key usage
Date: Thu, 8 Oct 2026 01:53:33 +0000 [thread overview]
Message-ID: <cd340d0b-31b0-490a-9961-78c5de117e70@transsion.com> (raw)
In-Reply-To: <xhsmhh5izyufq.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
On 10/6/2026 6:50 PM, Valentin Schneider wrote:
> On 03/09/26 11:57, Hongyan Xia wrote:
>> From: Hongyan Xia <hongyan.xia@transsion.com>
>>
>> Raw static keys have no type information and do not prevent mis-matches
>> (like static_key_false() on a default TRUE key). The helper names
>> static_key_{true/false}() are also confusing, hence the deprecation.
>>
>> We have already converted other sites in previous patches. Convert the
>> last sites of deprecated static key APIs. After this fix, scheduler code
>> has zero deprecated static key APIs now.
>>
>> sk_dynamic_* uses static_key_{enable/disable}(), which aren't really
>> deprecated, but take the opportunity to move to the new static_branch_*
>> APIs to be consistent.
>>
>> No functional change.
>>
>> Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
>
> Some comprehension/changelog explanation nit below, otherwise:
>
> Reviewed-by: Valentin Schneider <vschneid@redhat.com>
>
>> @@ -6575,21 +6575,21 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
>> #ifdef CONFIG_CFS_BANDWIDTH
>>
>> #ifdef CONFIG_JUMP_LABEL
>> -static struct static_key __cfs_bandwidth_used;
>> +static DEFINE_STATIC_KEY_FALSE(__cfs_bandwidth_used);
>>
>> static inline bool cfs_bandwidth_used(void)
>> {
>> - return static_key_false(&__cfs_bandwidth_used);
>> + return static_branch_unlikely(&__cfs_bandwidth_used);
>> }
>
> Usual likely/unlikely/true/false static key confusion for me here;
>
> The previous definition was pretty much
> = STATIC_KEY_INIT_FALSE
> due to static storage initialization.
>
> And then for the static_key_*() naming, false == unlikely.
>
> Because it's all #define magic I assume the compilation delta will be zero,
> but I can't be bothered given I'm on a laptop running power saver mode.
This is exactly what I checked before sending this patch. The good news
is that at least on my machine, the delta in the machine code is zero
under aarch64 and x86.
prev parent reply other threads:[~2026-10-08 1:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 11:57 Hongyan Xia
2026-10-06 10:50 ` Valentin Schneider
2026-10-06 11:01 ` Valentin Schneider
2026-10-08 1:53 ` Hongyan Xia [this message]
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=cd340d0b-31b0-490a-9961-78c5de117e70@transsion.com \
--to=hongyan.xia@transsion.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jiazi.li@transsion.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®