From: "yikai.lin" <yikai.lin@vivo.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Song Liu <song@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>
Cc: Christian Loehle <christian.loehle@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@fb.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Linux Power Management <linux-pm@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
zhaofuyu@vivo.com
Subject: Re: [PATCH v2 bpf-next 2/2] selftests/bpf: Add selftests for cpuidle_gov_ext
Date: Wed, 3 Sep 2025 11:06:18 +0800 [thread overview]
Message-ID: <8cdfe5bf-96a5-4aec-ad38-8136bf0f811d@vivo.com> (raw)
In-Reply-To: <CAADnVQ+iazLpRWtt219MqGD0LHVoccahG=Cf1w+Ow5xOjRd_Lg@mail.gmail.com>
On 9/3/2025 8:38 AM, Alexei Starovoitov wrote:
> [Some people who received this message don't often get email from alexei.starovoitov@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Mon, Sep 1, 2025 at 6:56 AM Lin Yikai <yikai.lin@vivo.com> wrote:
>>
>> +
>> +/*
>> + * For some low-power scenarios,
>> + * such as the screen off scenario of mobile devices
>> + * (which will be determined by the user-space BPF program),
>> + * we aim to choose a deeper state
>> + * At this point, we will somewhat disregard the impact on CPU performance.
>> + */
>> +int expect_deeper = 0;
>
> ...
>
>> +/* Select the next idle state */
>> +SEC("struct_ops.s/select")
>> +int BPF_PROG(bpf_cpuidle_select, struct cpuidle_driver *drv, struct cpuidle_device *dev)
>> +{
>> + u32 key = 0;
>> + s64 delta, latency_req, residency_ns;
>> + int i;
>> + unsigned long long disable;
>> + struct cpuidle_gov_data *data;
>> + struct cpuidle_state *cs;
>> +
>> + data = bpf_map_lookup_percpu_elem(&cpuidle_gov_data_map, &key, dev->cpu);
>> + if (!data) {
>> + bpf_printk("cpuidle_gov_ext: [%s] cpuidle_gov_data_map is NULL\n", __func__);
>> + return 0;
>> + }
>> + latency_req = bpf_cpuidle_ext_gov_latency_req(dev->cpu);
>> + delta = bpf_tick_nohz_get_sleep_length();
>> +
>> + update_predict_duration(data, drv, dev);
>> + for (i = ARRAY_SIZE(drv->states)-1; i > 0; i--) {
>> + if (i >= drv->state_count)
>> + continue;
>> + cs = &drv->states[i];
>> + disable = dev->states_usage[i].disable;
>> + if (disable)
>> + continue;
>> + if (latency_req < cs->exit_latency_ns)
>> + continue;
>> +
>> + if (delta < cs->target_residency_ns)
>> + continue;
>> +
>> + if (data->next_pred / FIT_FACTOR * ALPHA_SCALE < cs->target_residency_ns)
>> + continue;
>> +
>> + break;
>> + }
>> + residency_ns = drv->states[i].target_residency_ns;
>> + if (expect_deeper &&
>> + i <= drv->state_count-2 &&
>> + !dev->states_usage[i+1].disable &&
>> + data->last_pred >= residency_ns &&
>> + data->next_pred < residency_ns &&
>> + data->next_pred / FIT_FACTOR * ALPHA_SCALE >= residency_ns &&
>> + data->next_pred / FIT_FACTOR * ALPHA_SCALE >= data->last_duration &&
>> + delta > residency_ns) {
>> + i++;
>> + }
>> +
>> + return i;
>> +}
>
> This function is the main programmability benefit that
> you're claiming, right?
>
> And user space knob 'expect_deeper' is the key difference
> vs all existing governors ?
>
> If so, I have to agree with Rafael. This doesn't look too compelling
> to bolt bpf struct-ops onto cpuidle.
>
> There must be a way to introduce user togglable knobs in the current
> set of governors, no?
>
> Other than that the patch set seems to be doing all the right things
> from bpf perspective. KF_SLEEPABLE is missing in kfuncs and
> the safety aspect needs to be thoroughly analyzed,
> but before doing in-depth review the examples need to have more substance.
> With real world benchmarks and results.
> The commit log is saying:
> "This implementation serves as a foundation, not a final solution"
> It's understood that it's work-in-progress, but we need to see
> more real usage before committing.
Thanks, Alexei, Song, and Rafael, for your valuable feedback.
So, I understand that the key requirement here is to demonstrate a real-world scenario example
that can be effectively used in production environments
and to provide benchmark results.
Next up, I'll focus on developing a real-world use case for mobile devices
and providing test results.
Thanks again for the helpful insights.
next prev parent reply other threads:[~2025-09-03 3:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 13:56 [PATCHSET V2 bpf-next 0/2] cpuidle, bpf: Introduce BPF-ext cpuidle governor policy via struct_ops Lin Yikai
2025-09-01 13:56 ` [PATCH v2 bpf-next 1/2] cpuidle: Implement BPF extensible cpuidle governor class Lin Yikai
2025-09-07 6:15 ` kernel test robot
2025-09-01 13:56 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Add selftests for cpuidle_gov_ext Lin Yikai
2025-09-03 0:38 ` Alexei Starovoitov
2025-09-03 3:06 ` yikai.lin [this message]
2025-09-01 16:36 ` [PATCHSET V2 bpf-next 0/2] cpuidle, bpf: Introduce BPF-ext cpuidle governor policy via struct_ops Rafael J. Wysocki
2025-09-02 8:03 ` yikai.lin
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=8cdfe5bf-96a5-4aec-ad38-8136bf0f811d@vivo.com \
--to=yikai.lin@vivo.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christian.loehle@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=rafael@kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=yonghong.song@linux.dev \
--cc=zhaofuyu@vivo.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