[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200423091911.GP20730@hirez.programming.kicks-ass.net>
Date: Thu, 23 Apr 2020 11:19:11 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Marc Zyngier <maz@...nel.org>, Davidlohr Bueso <dave@...olabs.net>,
tglx@...utronix.de, kvm@...r.kernel.org,
Davidlohr Bueso <dbueso@...e.de>,
torvalds@...ux-foundation.org, bigeasy@...utronix.de,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
linux-mips@...r.kernel.org, Paul Mackerras <paulus@...abs.org>,
joel@...lfernandes.org, will@...nel.org,
kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH 4/5] kvm: Replace vcpu->swait with rcuwait
On Thu, Apr 23, 2020 at 10:57:57AM +0200, Paolo Bonzini wrote:
> On 23/04/20 10:41, Marc Zyngier wrote:
> >>
> >> - if (swait_active(kvm_arch_vcpu_wq(vcpu)))
> >> + if (rcu_dereference(kvm_arch_vpu_get_wait(vcpu)) != NULL)
> > This doesn't compile (wrong function name, and rcu_dereference takes a
> > variable). But whatever it would do if we fixed it looks dodgy. it isn't
> > the rcuwait structure that you want to dereference, but rcuwait->task
> > (we are checking whether we are called because we are blocking or being
> > preempted).
> >
>
> Yes, I agree. Replacing swait with rcuwait is all good, but please make
> the API look the same first. Just like you added prepare_to_rcuwait and
> finish_rcuwait, let's add rcuwait_active as well.
>
> Actually let's do it like this:
>
> 1) Davidlohr, please post only patches 1-3 to "equalize" the swait and
> rcuwait APIs.
>
> 2) Peter, please prepare a topic branch for those, or provide Acked-by
I don't think I have anything that conflicts with this, so sure, take
the whole thing through KVM.
For 1-3 (and I'll send a small niggle for 3 right after this):
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
I'll keep 5 as it is unrelated.
Powered by blists - more mailing lists