On Mon, Jun 27, 2016 at 10:09:59AM +0200, Peter Zijlstra wrote:
[snip]
>
> No, this is entirely insane, also broken.
>
> No vectors, no actual function calls, nothing like that. You want the
> below to completely compile away and generate the exact 100% same code
> it does today.
>
Point taken.
On 2016年06月27日 15:55, Peter Zijlstra wrote:
On Sun, Jun 26, 2016 at 12:59:01PM +0800, panxinhui wrote:
在 2016年6月26日，03:12，Peter Zijlstra 写道：
On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote:
by the way I still think mutex_unlock has a big overload too.
Do you mean overhead?
On Mon, Jun 27, 2016 at 02:45:06PM +0800, Boqun Feng wrote:
> +++ b/include/linux/vcpu_preempt.h
> @@ -0,0 +1,82 @@
> +/*
> + * Primitives for checking the vcpu preemption from the guest.
> + */
> +
> +static long __vcpu_preempt_count(void)
> +{
> + return 0;
> +}
> +
> +static bool __vcpu_has_
On Sun, Jun 26, 2016 at 12:59:01PM +0800, panxinhui wrote:
>
> > 在 2016年6月26日，03:12，Peter Zijlstra 写道：
> >
> > On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote:
> >
> >> by the way I still think mutex_unlock has a big overload too.
> >
> > Do you mean overhead?
> >
> oh, maybe you a
On 2016年06月27日 14:45, Boqun Feng wrote:
On Sun, Jun 26, 2016 at 02:59:26PM +0800, Boqun Feng wrote:
[snip]
This should be:
extern struct vcpu_preempt_ops vcpu_preempt_ops;
And I tested this one along with modified version of Xinhui's patch.
The test showed that even in a not over-committed
On Sun, Jun 26, 2016 at 02:59:26PM +0800, Boqun Feng wrote:
[snip]
>
> This should be:
>
> extern struct vcpu_preempt_ops vcpu_preempt_ops;
>
> And I tested this one along with modified version of Xinhui's patch.
>
> The test showed that even in a not over-committed system, the overhead
> of mu
> 在 2016年6月26日，22:11，Boqun Feng 写道：
>
> On Sun, Jun 26, 2016 at 02:58:00PM +0800, panxinhui wrote:
> [snip]
>>>
>>> Unfortunately, on PPC, we compile pseries code along with powernv code
>>> in a kernel binary, therefore we need to wire the proper primitives at
>>> runtime.
>>>
>> no, we
> 在 2016年6月26日，22:29，Boqun Feng 写道：
>
> On Sun, Jun 26, 2016 at 03:08:20PM +0800, panxinhui wrote:
> [snip]
>>> @@ -106,6 +109,9 @@ bool osq_lock(struct optimistic_spin_queue *lock)
>>> node->prev = prev;
>>> WRITE_ONCE(prev->next, node);
>>>
>>> + old = old - 1;
>>> + vpc = vcpu_pr
On Sun, Jun 26, 2016 at 03:08:20PM +0800, panxinhui wrote:
[snip]
> > @@ -106,6 +109,9 @@ bool osq_lock(struct optimistic_spin_queue *lock)
> > node->prev = prev;
> > WRITE_ONCE(prev->next, node);
> >
> > + old = old - 1;
> > + vpc = vcpu_preempt_count();
> > +
> > /*
> > * No
On Sun, Jun 26, 2016 at 02:58:00PM +0800, panxinhui wrote:
[snip]
> >>
> >
> > Unfortunately, on PPC, we compile pseries code along with powernv code
> > in a kernel binary, therefore we need to wire the proper primitives at
> > runtime.
> >
> no, we can use same vcpu preempted check ops actuall
> 在 2016年6月26日，14:59，Boqun Feng 写道：
>
> On Sun, Jun 26, 2016 at 02:10:57PM +0800, Boqun Feng wrote:
>> On Sun, Jun 26, 2016 at 01:21:04PM +0800, panxinhui wrote:
>>>
在 2016年6月26日，03:20，Peter Zijlstra 写道：
On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
>>> Would t
> 在 2016年6月26日，14:10，Boqun Feng 写道：
>
> On Sun, Jun 26, 2016 at 01:21:04PM +0800, panxinhui wrote:
>>
>>> 在 2016年6月26日，03:20，Peter Zijlstra 写道：
>>>
>>> On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
>> Would that not have issues where the owner cpu is kept running but the
On Sun, Jun 26, 2016 at 02:10:57PM +0800, Boqun Feng wrote:
> On Sun, Jun 26, 2016 at 01:21:04PM +0800, panxinhui wrote:
> >
> > > 在 2016年6月26日，03:20，Peter Zijlstra 写道：
> > >
> > > On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
> > Would that not have issues where the owner cpu
On Sun, Jun 26, 2016 at 01:21:04PM +0800, panxinhui wrote:
>
> > 在 2016年6月26日，03:20，Peter Zijlstra 写道：
> >
> > On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
> Would that not have issues where the owner cpu is kept running but the
> spinner (ie. _this_ vcpu) gets preempted?
> 在 2016年6月26日，03:20，Peter Zijlstra 写道：
>
> On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
Would that not have issues where the owner cpu is kept running but the
spinner (ie. _this_ vcpu) gets preempted? I would think that in that
case we too want to stop spinning.
>>>
> 在 2016年6月26日，03:12，Peter Zijlstra 写道：
>
> On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote:
>
>> by the way I still think mutex_unlock has a big overload too.
>
> Do you mean overhead?
>
oh, maybe you are right.
mutex_unlock ’s implementation uses inc_return variant on ppc, and
On Sat, Jun 25, 2016 at 09:20:25PM +0200, Peter Zijlstra wrote:
> On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
> > >> Would that not have issues where the owner cpu is kept running but the
> > >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that
> > >> case we too w
On Sat, Jun 25, 2016 at 09:20:25PM +0200, Peter Zijlstra wrote:
> On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
> > >> Would that not have issues where the owner cpu is kept running but the
> > >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that
> > >> case we too w
On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote:
> >> Would that not have issues where the owner cpu is kept running but the
> >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that
> >> case we too want to stop spinning.
> >>
> >
> do you mean that the spinner detect
On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote:
> by the way I still think mutex_unlock has a big overload too.
Do you mean overhead?
On Sun, Jun 26, 2016 at 12:28:13AM +0800, Boqun Feng wrote:
> On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote:
> > That works here, but it would not work for the need_resched() in
> > mutex_spin_on_owner() and mutex_optimistic_spin() which need equal
> > treatment.
> >
> > Because t
> 在 2016年6月26日，00:45，Boqun Feng 写道：
>
> On Sat, Jun 25, 2016 at 06:15:40PM +0200, Peter Zijlstra wrote:
>> On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote:
>>> So on PPC, we have lppaca::yield_count to detect when an vcpu is
>>> preempted, if the yield_count is even, the vcpu is runni
> 在 2016年6月26日，00:13，Peter Zijlstra 写道：
>
> On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote:
>> That works here, but it would not work for the need_resched() in
>> mutex_spin_on_owner() and mutex_optimistic_spin() which need equal
>> treatment.
>>
>> Because those too we want to
On Sat, Jun 25, 2016 at 06:15:40PM +0200, Peter Zijlstra wrote:
> On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote:
> > So on PPC, we have lppaca::yield_count to detect when an vcpu is
> > preempted, if the yield_count is even, the vcpu is running, otherwise it
> > is preempted(__spin_yie
On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote:
> On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote:
> > >
> > > int vpc = vcpu_preempt_count();
> > >
> > > ...
> > >
> > > for (;;) {
> > >
> > > /* the big spin loop */
> > >
> > > if (need_re
On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote:
> So on PPC, we have lppaca::yield_count to detect when an vcpu is
> preempted, if the yield_count is even, the vcpu is running, otherwise it
> is preempted(__spin_yield() is a user of this).
>
> Therefore it makes more sense we
>
>
On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote:
> That works here, but it would not work for the need_resched() in
> mutex_spin_on_owner() and mutex_optimistic_spin() which need equal
> treatment.
>
> Because those too we want to limit.
>
> The count thing, while a little more cum
On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote:
> >
> > int vpc = vcpu_preempt_count();
> >
> > ...
> >
> > for (;;) {
> >
> > /* the big spin loop */
> >
> > if (need_resched() || vpc != vcpu_preempt_count())
>
> So on PPC, we have lppaca::yiel
On Sat, Jun 25, 2016 at 04:24:47PM +0200, Peter Zijlstra wrote:
> On Sat, Jun 25, 2016 at 01:42:03PM -0400, Pan Xinhui wrote:
> > An over-committed guest with more vCPUs than pCPUs has a heavy overload
> > in osq_lock().
> >
> > This is because vCPU A hold the osq lock and yield out, vCPU B wait
>
On Sat, Jun 25, 2016 at 01:42:03PM -0400, Pan Xinhui wrote:
> An over-committed guest with more vCPUs than pCPUs has a heavy overload
> in osq_lock().
>
> This is because vCPU A hold the osq lock and yield out, vCPU B wait
> per_cpu node->locked to be set. IOW, vCPU B wait vCPU A to run and
> unlo
An over-committed guest with more vCPUs than pCPUs has a heavy overload
in osq_lock().
This is because vCPU A hold the osq lock and yield out, vCPU B wait
per_cpu node->locked to be set. IOW, vCPU B wait vCPU A to run and
unlock the osq lock. Even there is need_resched(), it did not help on
such s
31 matches
Mail list logo
