From: Thomas Gleixner <tglx@linutronix.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
Oleg Nesterov <oleg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Sebastian Siewior <bigeasy@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Julia Cartwright <julia@ni.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
kvm@vger.kernel.org, Radim Krcmar <rkrcmar@redhat.com>,
John Stultz <john.stultz@linaro.org>,
Andy Lutomirski <luto@kernel.org>,
"Paul E. McKenney" <paulmck@linux.ibm.com>
Subject: Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
Date: Sat, 3 Aug 2019 00:22:54 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1908030015330.4029@nanos.tec.linutronix.de> (raw)
In-Reply-To: <c8294b01-62d1-95df-6ff6-213f945a434f@redhat.com>
On Fri, 2 Aug 2019, Paolo Bonzini wrote:
> On 01/08/19 23:47, Thomas Gleixner wrote:
> > Right you are about cond_resched() being called, but for SRCU this does not
> > matter unless there is some way to do a synchronize operation on that SRCU
> > entity. It might have some other performance side effect though.
>
> I would use srcu_read_unlock/lock around the call.
>
> However, I'm wondering if the API can be improved because basically we
> have six functions for three checks of TIF flags. Does it make sense to
> have something like task_has_request_flags and task_do_requests (names
> are horrible I know) that can be used like
>
> if (task_has_request_flags()) {
> int err;
> ...srcu_read_unlock...
> // return -EINTR if signal_pending
> err = task_do_requests();
> if (err < 0)
> goto exit_no_srcu_read_unlock;
> ...srcu_read_lock...
> }
>
> taking care of all three cases with a single hook? This is important
> especially because all these checks are done by all KVM architectures in
> slightly different ways, and a unified API would be a good reason to
> make all architectures look the same.
>
> (Of course I could also define this unified API in virt/kvm/kvm_main.c,
> so this is not blocking the series in any way!).
You're not holding up something. Having a common function for this is
definitely the right approach.
As this is virt specific because it only checks for non arch specific bits
(TIF_NOTIFY_RESUME should be available for all KVM archs) and the TIF bits
are a subset of the available TIF bits because all others do not make any
sense there, this really should be a common function for KVM so that all
other archs which obviously lack a TIF_NOTIFY_RESUME check, can be fixed up
and consolidated. If we add another TIF check later then we only have to do
it in one place.
Thanks,
tglx
next prev parent reply other threads:[~2019-08-02 22:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 14:32 [patch 0/5] posix-cpu-timers: Move expiry into task work context Thomas Gleixner
2019-08-01 14:32 ` [patch 1/5] tracehook: Provide TIF_NOTIFY_RESUME handling for KVM Thomas Gleixner
2019-08-01 14:48 ` Peter Zijlstra
2019-08-01 15:10 ` Thomas Gleixner
2019-08-01 17:02 ` Andy Lutomirski
2019-08-01 14:32 ` [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT Thomas Gleixner
2019-08-01 16:24 ` Oleg Nesterov
2019-08-01 18:34 ` Thomas Gleixner
2019-08-01 21:35 ` Sean Christopherson
2019-08-01 21:44 ` Peter Zijlstra
2019-08-01 21:44 ` Thomas Gleixner
2019-08-01 21:47 ` Thomas Gleixner
2019-08-02 21:35 ` Paolo Bonzini
2019-08-02 22:22 ` Thomas Gleixner [this message]
2019-08-02 22:39 ` Andy Lutomirski
2019-08-02 12:04 ` Oleg Nesterov
2019-08-01 14:32 ` [patch 3/5] posix-cpu-timers: Split run_posix_cpu_timers() Thomas Gleixner
2019-08-01 14:32 ` [patch 4/5] posix-cpu-timers: Defer timer handling to task_work Thomas Gleixner
2019-08-01 14:51 ` Peter Zijlstra
2019-08-01 15:10 ` Thomas Gleixner
2019-08-01 15:39 ` Oleg Nesterov
2019-08-01 18:41 ` Thomas Gleixner
2019-08-01 14:32 ` [patch 5/5] x86: Select POSIX_CPU_TIMERS_TASK_WORK Thomas Gleixner
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=alpine.DEB.2.21.1908030015330.4029@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=john.stultz@linaro.org \
--cc=julia@ni.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sean.j.christopherson@intel.com \
--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).