All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wanpeng Li <kernellwp@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	mpe@ellerman.id.au, boqun.feng@gmail.com, will.deacon@arm.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Waiman Long <waiman.long@hpe.com>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
	benh@kernel.crashing.org, schwidefsky@de.ibm.com,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v2 0/4] implement vcpu preempted check
Date: Thu, 7 Jul 2016 18:27:26 +0800	[thread overview]
Message-ID: <CANRm+CxKVqrFB-cRPEvmUamZ5Y8cOGe3pyc0LMJy0t9_jo+i0Q@mail.gmail.com> (raw)
In-Reply-To: <CANRm+CyrPbOVpJ6-Wa=g6oXTU0vVfw-ciLgm-duZeVF6MBH=RA@mail.gmail.com>

2016-07-07 18:12 GMT+08:00 Wanpeng Li <kernellwp@gmail.com>:
> 2016-07-07 17:42 GMT+08:00 Peter Zijlstra <peterz@infradead.org>:
>> On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote:
>>> 2016-07-06 20:28 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>>> > Hmm, you're right.  We can use bit 0 of struct kvm_steal_time's flags to
>>> > indicate that pad[0] is a "VCPU preempted" field; if pad[0] is 1, the
>>> > VCPU has been scheduled out since the last time the guest reset the bit.
>>> >  The guest can use an xchg to test-and-clear it.  The bit can be
>>> > accessed at any time, independent of the version field.
>>>
>>> If one vCPU is preempted, and guest check it several times before this
>>> vCPU is scheded in, then the first time we can get "vCPU is
>>> preempted", however, since the field is cleared, the second time we
>>> will get "vCPU is running".
>>>
>>> Do you mean we should call record_steal_time() in both kvm_sched_in()
>>> and kvm_sched_out() to record this field? Btw, if we should keep both
>>> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present
>>> simultaneous?
>>
>> I suspect you want something like so; except this has holes in.
>>
>> We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it
>> after enabling it, this means that if we get preempted in between, the
>> vcpu is reported as running even though it very much is not.
>
> Paolo also point out this to me offline yesterday: "Please change
> pad[12] to "__u32 preempted; __u32 pad[11];" too, and remember to
> update Documentation/virtual/kvm/msr.txt!". Btw, do this in preemption
> notifier means that the vCPU is real preempted on host, however,
> depends on vmexit is different semantic I think.

In addition, I see xen's vcpu_runstate_info::state is updated during
schedule, so I think I can do this similarly through kvm preemption
notifier. IIUC, xen hypervisor has VCPUOP_get_runstate_info hypercall
implemention, so the desired interface can be implemented if they add
hypercall callsite in domU. I can add hypercall to kvm similarly.

Paolo, thoughts?

Regards,
Wanpeng Li

WARNING: multiple messages have this Message-ID (diff)
From: Wanpeng Li <kernellwp@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	benh@kernel.crashing.org, kvm <kvm@vger.kernel.org>,
	mpe@ellerman.id.au, boqun.feng@gmail.com, will.deacon@arm.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Waiman Long <waiman.long@hpe.com>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
	Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>,
	schwidefsky@de.ibm.com, Paolo Bonzini <pbonzini@redhat.com>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 0/4] implement vcpu preempted check
Date: Thu, 7 Jul 2016 18:27:26 +0800	[thread overview]
Message-ID: <CANRm+CxKVqrFB-cRPEvmUamZ5Y8cOGe3pyc0LMJy0t9_jo+i0Q@mail.gmail.com> (raw)
In-Reply-To: <CANRm+CyrPbOVpJ6-Wa=g6oXTU0vVfw-ciLgm-duZeVF6MBH=RA@mail.gmail.com>

2016-07-07 18:12 GMT+08:00 Wanpeng Li <kernellwp@gmail.com>:
> 2016-07-07 17:42 GMT+08:00 Peter Zijlstra <peterz@infradead.org>:
>> On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote:
>>> 2016-07-06 20:28 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>>> > Hmm, you're right.  We can use bit 0 of struct kvm_steal_time's flags to
>>> > indicate that pad[0] is a "VCPU preempted" field; if pad[0] is 1, the
>>> > VCPU has been scheduled out since the last time the guest reset the bit.
>>> >  The guest can use an xchg to test-and-clear it.  The bit can be
>>> > accessed at any time, independent of the version field.
>>>
>>> If one vCPU is preempted, and guest check it several times before this
>>> vCPU is scheded in, then the first time we can get "vCPU is
>>> preempted", however, since the field is cleared, the second time we
>>> will get "vCPU is running".
>>>
>>> Do you mean we should call record_steal_time() in both kvm_sched_in()
>>> and kvm_sched_out() to record this field? Btw, if we should keep both
>>> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present
>>> simultaneous?
>>
>> I suspect you want something like so; except this has holes in.
>>
>> We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it
>> after enabling it, this means that if we get preempted in between, the
>> vcpu is reported as running even though it very much is not.
>
> Paolo also point out this to me offline yesterday: "Please change
> pad[12] to "__u32 preempted; __u32 pad[11];" too, and remember to
> update Documentation/virtual/kvm/msr.txt!". Btw, do this in preemption
> notifier means that the vCPU is real preempted on host, however,
> depends on vmexit is different semantic I think.

In addition, I see xen's vcpu_runstate_info::state is updated during
schedule, so I think I can do this similarly through kvm preemption
notifier. IIUC, xen hypervisor has VCPUOP_get_runstate_info hypercall
implemention, so the desired interface can be implemented if they add
hypercall callsite in domU. I can add hypercall to kvm similarly.

Paolo, thoughts?

Regards,
Wanpeng Li

  reply	other threads:[~2016-07-07 10:27 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28 14:43 [PATCH v2 0/4] implement vcpu preempted check Pan Xinhui
2016-06-28 14:43 ` Pan Xinhui
2016-06-28 14:43 ` [PATCH v2 1/4] kernel/sched: introduce vcpu preempted check interface Pan Xinhui
2016-06-28 14:43   ` Pan Xinhui
2016-06-28 14:43 ` [PATCH v2 2/4] powerpc/spinlock: support vcpu preempted check Pan Xinhui
2016-06-28 14:43   ` Pan Xinhui
2016-07-05  9:57   ` Wanpeng Li
2016-07-05  9:57   ` Wanpeng Li
2016-07-06  4:58     ` xinhui
2016-07-06  4:58       ` xinhui
2016-07-06  6:46       ` Wanpeng Li
2016-07-06  6:46         ` Wanpeng Li
2016-07-06  6:46         ` Wanpeng Li
2016-07-06  7:58         ` Peter Zijlstra
2016-07-06  7:58           ` Peter Zijlstra
2016-07-06  8:32           ` Wanpeng Li
2016-07-06  8:32             ` Wanpeng Li
2016-07-06 10:18             ` xinhui
2016-07-06 10:18               ` xinhui
2016-07-06 10:54   ` Balbir Singh
2016-07-06 10:54     ` Balbir Singh
2016-07-06 10:54     ` Balbir Singh
2016-07-15 15:35     ` Pan Xinhui
2016-07-15 15:35     ` Pan Xinhui
2016-06-28 14:43 ` [PATCH v2 3/4] locking/osq: Drop the overload of osq_lock() Pan Xinhui
2016-06-28 14:43 ` Pan Xinhui
2016-06-28 14:43 ` [PATCH v2 4/4] kernel/locking: Drop the overload of {mutex,rwsem}_spin_on_owner Pan Xinhui
2016-06-28 14:43   ` [PATCH v2 4/4] kernel/locking: Drop the overload of {mutex, rwsem}_spin_on_owner Pan Xinhui
2016-06-28 14:43   ` Pan Xinhui
2016-07-06  6:52 ` [PATCH v2 0/4] implement vcpu preempted check Peter Zijlstra
2016-07-06  6:52   ` Peter Zijlstra
2016-07-06  7:47   ` Juergen Gross
2016-07-06  7:47     ` Juergen Gross
2016-07-06  8:19     ` Peter Zijlstra
2016-07-06  8:19       ` Peter Zijlstra
2016-07-06  8:38       ` Juergen Gross
2016-07-06  8:38         ` Juergen Gross
2016-07-06 12:44       ` Paolo Bonzini
2016-07-06 12:44         ` Paolo Bonzini
2016-07-06 16:56       ` Christian Borntraeger
2016-07-06 16:56         ` Christian Borntraeger
2016-07-06 16:56         ` Christian Borntraeger
2016-07-06 10:05   ` xinhui
2016-07-06 10:05     ` xinhui
2016-07-06 10:44   ` Paolo Bonzini
2016-07-06 11:59     ` Peter Zijlstra
2016-07-06 11:59     ` Peter Zijlstra
2016-07-06 12:08     ` Wanpeng Li
2016-07-06 12:08       ` Wanpeng Li
2016-07-06 12:28       ` Paolo Bonzini
2016-07-06 12:28         ` Paolo Bonzini
2016-07-06 13:03         ` Wanpeng Li
2016-07-06 13:03           ` Wanpeng Li
2016-07-07  8:48         ` Wanpeng Li
2016-07-07  8:48           ` Wanpeng Li
2016-07-07  9:42           ` Peter Zijlstra
2016-07-07  9:42             ` Peter Zijlstra
2016-07-07 10:12             ` Wanpeng Li
2016-07-07 10:12               ` Wanpeng Li
2016-07-07 10:27               ` Wanpeng Li [this message]
2016-07-07 10:27                 ` Wanpeng Li
2016-07-07 11:15                 ` Peter Zijlstra
2016-07-07 11:15                   ` Peter Zijlstra
2016-07-07 11:08               ` Peter Zijlstra
2016-07-07 11:08                 ` Peter Zijlstra
2016-07-07 11:09             ` Peter Zijlstra
2016-07-07 11:09               ` Peter Zijlstra
2016-07-07 11:21             ` Peter Zijlstra
2016-07-07 11:21               ` Peter Zijlstra
2016-07-11 15:10   ` Waiman Long
2016-07-11 15:10     ` Waiman Long
2016-07-11 15:10     ` Waiman Long
2016-07-12  4:16     ` Juergen Gross
2016-07-12  4:16     ` Juergen Gross
2016-07-12 18:16       ` Waiman Long
2016-07-12 18:16         ` Waiman Long
2016-07-12 18:16         ` Waiman Long

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=CANRm+CxKVqrFB-cRPEvmUamZ5Y8cOGe3pyc0LMJy0t9_jo+i0Q@mail.gmail.com \
    --to=kernellwp@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=waiman.long@hpe.com \
    --cc=will.deacon@arm.com \
    --cc=xinhui.pan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.