kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Sean Christopherson <sean.j.christopherson@intel.com>
Cc: 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: Fri, 2 Aug 2019 23:35:36 +0200	[thread overview]
Message-ID: <c8294b01-62d1-95df-6ff6-213f945a434f@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908012345000.1789@nanos.tec.linutronix.de>

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!).

Paolo

  reply	other threads:[~2019-08-02 21:35 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 [this message]
2019-08-02 22:22               ` Thomas Gleixner
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=c8294b01-62d1-95df-6ff6-213f945a434f@redhat.com \
    --to=pbonzini@redhat.com \
    --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=peterz@infradead.org \
    --cc=rkrcmar@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --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).