From: Ankur Arora <ankur.a.arora@oracle.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
pbonzini@redhat.com, wanpengli@tencent.com, vkuznets@redhat.com,
rafael@kernel.org, daniel.lezcano@linaro.org,
peterz@infradead.org, arnd@arndb.de, lenb@kernel.org,
mark.rutland@arm.com, harisokn@amazon.com,
boris.ostrovsky@oracle.com, konrad.wilk@oracle.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/9] cpuidle-haltpoll: define arch_haltpoll_supported()
Date: Tue, 04 Jun 2024 22:47:17 -0700 [thread overview]
Message-ID: <87mso0ym8q.fsf@oracle.com> (raw)
In-Reply-To: <3f72519e-bf82-458f-a066-0c296a7d655f@oracle.com>
Joao Martins <joao.m.martins@oracle.com> writes:
> On 30/04/2024 19:37, Ankur Arora wrote:
>> From: Joao Martins <joao.m.martins@oracle.com>
>>
>> Right now kvm_para_has_hint(KVM_HINTS_REALTIME) is x86 only. In
>> pursuit of making cpuidle-haltpoll architecture independent, define
>> arch_haltpoll_supported() which handles the architectural check for
>> enabling haltpoll.
>>
>> Move the (kvm_para_available() && kvm_para_has_hint(KVM_HINTS_REALTIME))
>> check to the x86 specific arch_haltpoll_supported().
>>
>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>> Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com>
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>>
>> ---
>> Changelog:
>>
>> - s/arch_haltpoll_want/arch_haltpoll_supported/
>
>
> I am not sure it's correct to call supported() considering that it's supposed to
> always supported (via WFE or cpu_relax()) and it's not exactly what it is doing.
> The function you were changing is more about whether it's default enabled or
> not. So I think the old name in v4 is more appropriate i.e. arch_haltpoll_want()
>
> Alternatively you could have it called arch_haltpoll_default_enabled() though
> it's longer/verbose.
So, I thought about it some and the driver loading decision tree
should be:
1. bail out based on the value of boot_option_idle_override.
2. if arch_haltpoll_supported(), enable haltpoll
3. if cpuidle-haltpoll.force=1, enable haltpoll,
Note: in the posted versions, cpuidle-haltpoll.force is allowed to
override boot_option_idle_override, which is wrong. With that fixed
the x86 check should be:
bool arch_haltpoll_supported(void)
{
return kvm_para_available() && kvm_para_has_hint(KVM_HINTS_REALTIME);
}
and arm64:
static inline bool arch_haltpoll_supported(void)
{
/*
* Ensure the event stream is available to provide a terminating
* condition to the WFE in the poll loop.
*/
return arch_timer_evtstrm_available();
}
Now, both of these fit reasonably well with arch_haltpoll_supported().
My personal preference for that is because it seems to me that the
architecture code should just deal with mechanism and not policy.
However, as you imply arch_haltpoll_supported() is a more loaded name
and given that the KVM side of arm64 haltpoll is not done yet, it's
best to have a more neutral label like arch_haltpoll_want() or
arch_haltpoll_do_enable().
> Though if you want a true supported() arch helper *I think* you need to make a
> bigger change into introducing arch_haltpoll_supported() separate from
> arch_haltpoll_want() where the former would ignore the .force=y modparam and
> never be able to load if a given feature wasn't present e.g. prevent arm64
> haltpoll loading be conditioned to arch_timer_evtstrm_available() being present.
>
> Though I don't think that you want this AIUI
Yeah I don't. I think the cpuidle-haltpoll.force=1, should be allowed to
override arch_haltpoll_supported(), so long as smp_cond_load_relaxed()
is well defined (as it is here).
It shouldn't, however, override the user's choice of boot_option_idle_override.
--
ankur
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-06-05 5:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 18:37 [PATCH 0/9] Enable haltpoll for arm64 Ankur Arora
2024-04-30 18:37 ` [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED_POLL Ankur Arora
2024-05-02 1:33 ` Christoph Lameter (Ampere)
2024-05-03 4:13 ` Ankur Arora
2024-05-03 17:07 ` Christoph Lameter (Ampere)
2024-05-06 21:27 ` Ankur Arora
2024-04-30 18:37 ` [PATCH 2/9] Kconfig: move ARCH_HAS_OPTIMIZED_POLL to arch/Kconfig Ankur Arora
2024-04-30 18:37 ` [PATCH 3/9] cpuidle-haltpoll: condition on ARCH_CPUIDLE_HALTPOLL Ankur Arora
2024-05-22 16:09 ` Joao Martins
2024-04-30 18:37 ` [PATCH 4/9] cpuidle-haltpoll: define arch_haltpoll_supported() Ankur Arora
2024-05-01 11:48 ` kernel test robot
2024-05-22 16:09 ` Joao Martins
2024-06-05 5:47 ` Ankur Arora [this message]
2024-04-30 18:37 ` [PATCH 5/9] governors/haltpoll: drop kvm_para_available() check Ankur Arora
2024-04-30 18:37 ` [PATCH 6/9] cpuidle/poll_state: poll via smp_cond_load_relaxed() Ankur Arora
2024-04-30 18:37 ` [PATCH 7/9] arm64: define TIF_POLLING_NRFLAG Ankur Arora
2024-04-30 18:37 ` [PATCH 8/9] arm64: support cpuidle-haltpoll Ankur Arora
2024-05-30 23:07 ` Okanovic, Haris
2024-06-04 23:09 ` Ankur Arora
2024-06-19 12:17 ` Sudeep Holla
2024-06-21 23:59 ` Ankur Arora
2024-06-24 10:54 ` Sudeep Holla
2024-06-25 1:17 ` Ankur Arora
2024-04-30 18:37 ` [PATCH 9/9] cpuidle/poll_state: limit POLL_IDLE_RELAX_COUNT on arm64 Ankur Arora
2024-04-30 18:56 ` [PATCH 0/9] Enable haltpoll for arm64 Ankur Arora
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=87mso0ym8q.fsf@oracle.com \
--to=ankur.a.arora@oracle.com \
--cc=arnd@arndb.de \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=harisokn@amazon.com \
--cc=hpa@zytor.com \
--cc=joao.m.martins@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).