Linux Kernel Selftest development
 help / color / mirror / Atom feed
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.



  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