[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ab78bbc8-aa03-6e88-940e-5e1c041f48e4@redhat.com>
Date: Tue, 21 Apr 2020 21:52:47 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Davidlohr Bueso <dave@...olabs.net>
Cc: Marc Zyngier <maz@...nel.org>, tglx@...utronix.de,
kvm@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>,
peterz@...radead.org, 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 v2] kvm: Replace vcpu->swait with rcuwait
On 21/04/20 20:07, Davidlohr Bueso wrote:
>>
>
> I should have looked closer here - I was thinking about the return
> value of rcuwait_wait_event. Yes, that signal_pending check you
> mention makes the sleep semantics change bogus as interruptible is no
> longer just to avoid contributing to the load balance.
>
> And yes, unfortunately adding prepare_to and finish_rcuwait() looks
> like the most reasonable approach to keeping the tracepoint
> semantics. I also considered extending rcuwait_wait_event() by
> another parameter to pass back to the caller if there was any wait at
> all, but that enlarges the call and is probably less generic.
Yes, at some point the usual prepare_to/finish APIs become simpler.
> I'll send another version keeping the current sleep and tracepoint
> semantics.
Thanks---and sorry, I should have noticed that way earlier.
Paolo
Powered by blists - more mailing lists