linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Christoph Lameter (Ampere)" <cl@gentwo.org>,
	Ankur Arora <ankur.a.arora@oracle.com>,
	linux-pm@vger.kernel.org, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, will@kernel.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, 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, mtosatti@redhat.com,
	sudeep.holla@arm.com, misono.tomohiro@fujitsu.com,
	maobibo@loongson.cn, joao.m.martins@oracle.com,
	boris.ostrovsky@oracle.com, konrad.wilk@oracle.com
Subject: Re: [PATCH v8 01/11] cpuidle/poll_state: poll via smp_cond_load_relaxed()
Date: Tue, 15 Oct 2024 14:53:58 -0700	[thread overview]
Message-ID: <87jze9rq15.fsf@oracle.com> (raw)
In-Reply-To: <Zw6o_OyhzYd6hfjZ@arm.com>


Catalin Marinas <catalin.marinas@arm.com> writes:

> On Tue, Oct 15, 2024 at 10:17:13AM -0700, Christoph Lameter (Ampere) wrote:
>> On Tue, 15 Oct 2024, Catalin Marinas wrote:
>> > > Setting of need_resched() from another processor involves sending an IPI
>> > > after that was set. I dont think we need to smp_cond_load_relaxed since
>> > > the IPI will cause an event. For ARM a WFE would be sufficient.
>> >
>> > I'm not worried about the need_resched() case, even without an IPI it
>> > would still work.
>> >
>> > The loop_count++ side of the condition is supposed to timeout in the
>> > absence of a need_resched() event. You can't do an smp_cond_load_*() on
>> > a variable that's only updated by the waiting CPU. Nothing guarantees to
>> > wake it up to update the variable (the event stream on arm64, yes, but
>> > that's generic code).
>>
>> Hmm... I have WFET implementation here without smp_cond modelled after
>> the delay() implementation ARM64 (but its not generic and there is
>> an additional patch required to make this work. Intermediate patch
>> attached)
>
> At least one additional patch ;). But yeah, I suggested hiding all this
> behind something like smp_cond_load_timeout() which would wait on
> current_thread_info()->flags but with a timeout. The arm64
> implementation would follow some of the logic in __delay(). Others may
> simply poll with cpu_relax().
>
> Alternatively, if we get an IPI anyway, we can avoid smp_cond_load() and
> rely on need_resched() and some new delay/cpu_relax() API that waits for
> a timeout or an IPI, whichever comes first. E.g. cpu_relax_timeout()
> which on arm64 it's just a simplified version of __delay() without the
> 'while' loops.

AFAICT when polling (which we are since poll_idle() calls
current_set_polling_and_test()), the scheduler will elide the IPI
by remotely setting the need-resched bit via set_nr_if_polling().

Once we stop polling then the scheduler should take the IPI path
because call_function_single_prep_ipi() will fail.

--
ankur


  reply	other threads:[~2024-10-15 21:56 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25 23:24 [PATCH v8 00/11] Enable haltpoll on arm64 Ankur Arora
2024-09-25 23:24 ` [PATCH v8 01/11] cpuidle/poll_state: poll via smp_cond_load_relaxed() Ankur Arora
2024-10-15 12:04   ` Catalin Marinas
2024-10-15 16:42     ` Christoph Lameter (Ampere)
2024-10-15 16:50       ` Catalin Marinas
2024-10-15 17:17         ` Christoph Lameter (Ampere)
2024-10-15 17:40           ` Catalin Marinas
2024-10-15 21:53             ` Ankur Arora [this message]
2024-10-15 22:28               ` Christoph Lameter (Ampere)
2024-10-16  7:06                 ` Ankur Arora
2024-10-17 16:54                   ` Christoph Lameter (Ampere)
2024-10-17 18:36                     ` Ankur Arora
2024-10-15 22:40               ` Christoph Lameter (Ampere)
2024-10-16  9:54                 ` Catalin Marinas
2024-10-17 16:56                   ` Christoph Lameter (Ampere)
2024-10-17 18:15                     ` Catalin Marinas
2024-10-17 19:34                       ` Ankur Arora
2024-10-15 21:32     ` Ankur Arora
2024-10-16  6:20       ` maobibo
2024-10-16 10:06       ` Catalin Marinas
2024-10-16 15:13     ` Okanovic, Haris
2024-10-16 17:04       ` Ankur Arora
2024-10-16 18:04         ` Okanovic, Haris
2024-10-17 14:01       ` Catalin Marinas
2024-10-17 22:47         ` Ankur Arora
2024-10-18 11:05           ` Catalin Marinas
2024-10-18 19:00             ` Ankur Arora
2024-10-21 12:02               ` Catalin Marinas
2024-09-25 23:24 ` [PATCH v8 02/11] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED_POLL Ankur Arora
2024-09-25 23:24 ` [PATCH v8 03/11] Kconfig: move ARCH_HAS_OPTIMIZED_POLL to arch/Kconfig Ankur Arora
2024-09-25 23:24 ` [PATCH v8 04/11] cpuidle-haltpoll: define arch_haltpoll_want() Ankur Arora
2024-09-25 23:24 ` [PATCH v8 05/11] governors/haltpoll: drop kvm_para_available() check Ankur Arora
2024-09-25 23:24 ` [PATCH v8 06/11] cpuidle-haltpoll: condition on ARCH_CPUIDLE_HALTPOLL Ankur Arora
2024-09-25 23:24 ` [PATCH v8 07/11] arm64: define TIF_POLLING_NRFLAG Ankur Arora
2024-09-25 23:24 ` [PATCH v8 08/11] arm64: idle: export arch_cpu_idle Ankur Arora
2024-09-25 23:24 ` [PATCH v8 09/11] arm64: select ARCH_HAS_OPTIMIZED_POLL Ankur Arora
2024-09-25 23:24 ` [PATCH v8 10/11] cpuidle/poll_state: limit POLL_IDLE_RELAX_COUNT on arm64 Ankur Arora
2024-09-25 23:24 ` [PATCH v8 11/11] arm64: support cpuidle-haltpoll Ankur Arora
2024-10-02 22:42   ` Okanovic, Haris
2024-10-03  3:29     ` Ankur Arora
2024-10-16 15:13   ` Okanovic, Haris
2024-10-09  2:37 ` [PATCH v8 00/11] Enable haltpoll on arm64 zhenglifeng (A)
2024-10-15  1:53   ` Ankur Arora
2024-10-14 22:54 ` Christoph Lameter (Ampere)
2024-10-15 12:36 ` Marc Zyngier
2024-10-16 21:55   ` Ankur Arora
2024-10-17  8:19     ` Marc Zyngier
2024-10-17 18:35       ` Ankur Arora
2024-10-22 22:01         ` Ankur Arora
2024-11-05 18:30 ` Haris Okanovic
2024-11-05 18:30   ` [PATCH 1/5] asm-generic: add smp_vcond_load_relaxed() Haris Okanovic
2024-11-05 19:36     ` Christoph Lameter (Ampere)
2024-11-06 17:06       ` Okanovic, Haris
2024-11-06 11:08     ` Catalin Marinas
2024-11-06 18:13       ` Okanovic, Haris
2024-11-06 19:55         ` Catalin Marinas
2024-11-06 20:31           ` Okanovic, Haris
2024-11-06 11:39     ` Will Deacon
2024-11-06 17:18       ` Okanovic, Haris
2024-11-05 18:30   ` [PATCH 2/5] arm64: add __READ_ONCE_EX() Haris Okanovic
2024-11-05 19:39     ` Christoph Lameter (Ampere)
2024-11-06 17:37       ` Okanovic, Haris
2024-11-06 11:43     ` Will Deacon
2024-11-06 17:09       ` Okanovic, Haris
2024-11-09  9:49     ` David Laight
2024-11-05 18:30   ` [PATCH 3/5] arm64: refactor delay() to enable polling for value Haris Okanovic
2024-11-05 19:42     ` Christoph Lameter (Ampere)
2024-11-06 17:42       ` Okanovic, Haris
2024-11-06  9:18     ` Catalin Marinas
2024-11-06 17:38       ` Okanovic, Haris
2024-11-05 18:30   ` [PATCH 4/5] arm64: add smp_vcond_load_relaxed() Haris Okanovic
2024-11-05 18:30   ` [PATCH 5/5] cpuidle: implement poll_idle() using smp_vcond_load_relaxed() Haris Okanovic
2024-11-05 19:45     ` Christoph Lameter (Ampere)
2024-11-05 18:49   ` [PATCH v8 00/11] Enable haltpoll on 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=87jze9rq15.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=cl@gentwo.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --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=maobibo@loongson.cn \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=misono.tomohiro@fujitsu.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --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).