All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Rik van Riel <riel@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Srikar <srikar@linux.vnet.ibm.com>,
	S390 <linux-s390@vger.kernel.org>,
	Carsten Otte <cotte@de.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	KVM <kvm@vger.kernel.org>, chegu vinod <chegu_vinod@hp.com>,
	"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	linux390@de.ibm.com,
	Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>,
	Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [PATCH RFC V4 3/3] kvm: Choose better candidate for directed yield
Date: Tue, 17 Jul 2012 14:39:09 +0530	[thread overview]
Message-ID: <50052BB5.2040909@linux.vnet.ibm.com> (raw)
In-Reply-To: <50052272.5020803@redhat.com>

On 07/17/2012 01:59 PM, Avi Kivity wrote:
> On 07/16/2012 07:10 PM, Rik van Riel wrote:
>> On 07/16/2012 06:07 AM, Avi Kivity wrote:
>>
>>>> +{
>>>> +    bool eligible;
>>>> +
>>>> +    eligible = !vcpu->ple.cpu_relax_intercepted ||
>>>> +            (vcpu->ple.cpu_relax_intercepted&&
>>>> +             vcpu->ple.dy_eligible);
>>>> +
>>>> +    if (vcpu->ple.cpu_relax_intercepted)
>>>> +        vcpu->ple.dy_eligible = !vcpu->ple.dy_eligible;
>>>
>>> Probably should assign 'true', since the previous value is essentially
>>> random.
>>
>> I suspect the intended purpose of this conditional is to
>> flip the eligibility of a vcpu for being selected as a
>> direct yield target.
>>
>> In other words, that bit of the code is correct.
>
> If vcpu A is in a long spin loop and is preempted away, and vcpu B dips
> several times in kvm_vcpu_on_spin(), then it will act as intended.

Yes, true.

But
> if vcpu A is spinning for x% of its time and processing on the other,
> then vcpu B will flip its dy_eligible for those x%, and not flip it when
> it's processing.  I don't understand how this is useful.

Suppose A is doing really good job and and has not done pause loop
exit, we will not touch it's dy_eligible flag. Also dy_eligible flag
will not prevent B doing yield_to to A.

Suppose A has started spinning in the beginning itself, it will do pause 
loop exit if it crosses threshold, and we will now start toggling
dy_eligible.

Was that you were referring?

And it seems we may still have to set dy_eligible flag to false at the 
beginning of vcpu_on_spin along with cpu_relax_intercepted = true, like 
below, so that we do not have spill-over status from previous PL exits.

vcpu_on_spin()
{
  cpu_relax_intercepted = true;
  dy_eligible = false;
.
.
.

cpu_relax_intercepted = false;
}

Let me know if that addresses your concern.

>
> I guess this is an attempt to impose fairness on yielding, and it makes
> sense to do this, but I don't know if this is the best way to achieve it.
>

  reply	other threads:[~2012-07-17  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16  8:24 [PATCH RFC V4 0/3] kvm: Improving directed yield in PLE handler Raghavendra K T
2012-07-16  8:25 ` [PATCH RFC V4 1/3] kvm/config: Add config to support ple or cpu relax optimzation Raghavendra K T
2012-07-16  8:25 ` [PATCH RFC V4 2/3] kvm: Note down when cpu relax intercepted or pause loop exited Raghavendra K T
2012-07-16 10:01   ` Avi Kivity
2012-07-16 17:24     ` Raghavendra K T
2012-07-17  8:22       ` Avi Kivity
2012-07-17  8:31         ` Raghavendra K T
2012-07-16  8:25 ` [PATCH RFC V4 3/3] kvm: Choose better candidate for directed yield Raghavendra K T
2012-07-16 10:07   ` Avi Kivity
2012-07-16 16:10     ` Rik van Riel
2012-07-16 17:07       ` Raghavendra K T
2012-07-17  8:29       ` Avi Kivity
2012-07-17  9:09         ` Raghavendra K T [this message]
2012-07-18  2:28           ` Raghavendra K T
2012-07-16 17:49     ` Raghavendra K T

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=50052BB5.2040909@linux.vnet.ibm.com \
    --to=raghavendra.kt@linux.vnet.ibm.com \
    --cc=avi@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=chegu_vinod@hp.com \
    --cc=cotte@de.ibm.com \
    --cc=gleb@redhat.com \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=riel@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=srivatsa.vaddagiri@gmail.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 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.