From: Nathan Lynch <nathanl@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org
Cc: srikar@linux.vnet.ibm.com, npiggin@gmail.com
Subject: Re: [PATCH] powerpc/paravirt: correct preempt debug splat in vcpu_is_preempted()
Date: Wed, 22 Sep 2021 10:28:12 -0500 [thread overview]
Message-ID: <87h7ecocj7.fsf@linux.ibm.com> (raw)
In-Reply-To: <87fstxi0hc.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> --- a/arch/powerpc/include/asm/paravirt.h
>> +++ b/arch/powerpc/include/asm/paravirt.h
>> @@ -97,7 +97,14 @@ static inline bool vcpu_is_preempted(int cpu)
>>
>> #ifdef CONFIG_PPC_SPLPAR
>> if (!is_kvm_guest()) {
>> - int first_cpu = cpu_first_thread_sibling(smp_processor_id());
>> + int first_cpu;
>> +
>> + /*
>> + * This is only a guess at best, and this function may be
>> + * called with preemption enabled. Using raw_smp_processor_id()
>> + * does not damage accuracy.
>> + */
>> + first_cpu = cpu_first_thread_sibling(raw_smp_processor_id());
>
> This change seems good, except I think the comment needs to be a lot
> more explicit about what it's doing and why.
>
> A casual reader is going to be confused about vcpu preemption vs
> "preemption", which are basically unrelated yet use the same word.
>
> It's not clear how raw_smp_processor_id() is related to (Linux)
> preemption, unless you know that smp_processor_id() is the alternative
> and it contains a preemption check.
>
> And "this is only a guess" is not clear on what *this* is, you're
> referring to the result of the whole function, but that's not obvious.
You're right.
>
>> /*
>> * Preemption can only happen at core granularity. This CPU
> ^^^^^^^^^^
> Means something different to "preemption" above.
>
> I know you didn't write that comment, and maybe we need to rewrite some
> of those existing comments to make it clear they're not talking about
> Linux preemption.
Thanks, agreed on all points. I'll rework the existing comments and any
new ones to clearly distinguish between the two senses of preemption
here.
next prev parent reply other threads:[~2021-09-22 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 3:12 [PATCH] powerpc/paravirt: correct preempt debug splat in vcpu_is_preempted() Nathan Lynch
2021-09-22 6:32 ` Michael Ellerman
2021-09-22 15:28 ` Nathan Lynch [this message]
2021-09-22 7:57 ` Srikar Dronamraju
2021-09-22 16:01 ` Nathan Lynch
2021-09-22 16:33 ` Srikar Dronamraju
2021-09-22 19:29 ` Nathan Lynch
2021-09-23 7:29 ` Michael Ellerman
2021-09-23 18:02 ` Srikar Dronamraju
2021-09-24 3:07 ` Michael Ellerman
2021-09-25 0:10 ` Nathan Lynch
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=87h7ecocj7.fsf@linux.ibm.com \
--to=nathanl@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=srikar@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).