linux-kernel - Re: [PATCH V2 RFC 2/3] kvm: Handle yield_to failure return code for potential undercommit case

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50915A91.1040001@linux.vnet.ibm.com>
Date:	Wed, 31 Oct 2012 22:36:25 +0530
From:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Rik van Riel <riel@...hat.com>,
	Srikar <srikar@...ux.vnet.ibm.com>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	KVM <kvm@...r.kernel.org>, Jiannan Ouyang <ouyang@...pitt.edu>,
	Chegu Vinod <chegu_vinod@...com>,
	"Andrew M. Theurer" <habanero@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Srivatsa Vaddagiri <srivatsa.vaddagiri@...il.com>,
	Gleb Natapov <gleb@...hat.com>,
	Andrew Jones <drjones@...hat.com>
Subject: Re: [PATCH V2 RFC 2/3] kvm: Handle yield_to failure return code for
 potential undercommit case

On 10/31/2012 07:11 PM, Avi Kivity wrote:
> On 10/31/2012 03:15 PM, Raghavendra K T wrote:
>> On 10/31/2012 06:11 PM, Raghavendra K T wrote:
>>> On 10/31/2012 06:08 PM, Avi Kivity wrote:
>>>> On 10/29/2012 04:07 PM, Raghavendra K T wrote:
>>>>> From: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
>>>>>
>>>>> Also we do not update last boosted vcpu in failure cases.
>>>>>
>>>>>    #endif
>>>>> +
>>>>>    void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>>    {
>>>>>        struct kvm *kvm = me->kvm;
>>>>> @@ -1727,11 +1727,12 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>>>>>                    continue;
>>>>>                if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
>>>>>                    continue;
>>>>> -            if (kvm_vcpu_yield_to(vcpu)) {
>>>>> +
>>>>> +            yielded = kvm_vcpu_yield_to(vcpu);
>>>>> +            if (yielded > 0)
>>>>>                    kvm->last_boosted_vcpu = i;
>>>>> -                yielded = 1;
>>>>> +            if (yielded)
>>>>>                    break;
>>>>> -            }
>>>>>            }
>>>>
>>>> If yielded == -ESRCH, should we not try to yield to another vcpu?
>>>>
>>>
>>>    Yes. plan is to abort the iteration. since it means we are mostly
>>> undercommitted.
>>
>> Sorry if it was ambiguous. I wanted to say we do not want to continue
>> yield to another vcpu..
>>
>
>
> Why not?  We found that this particular vcpu is running and therefore
> likely not a lock holder.  That says nothing about other vcpus.  The
> next in line might be runnable-but-not-running on another runqueue.

Agree that next in the line might be runnable-not-running.  But here we
are optimistic that, that is not the case and we save time by
returning back instead of iterating, thinking we are mostly in
undercommitted case and each vcpu has dedicated cpu.

Probably an alternative we have here is to look for say 2-3 successive
failures before breaking out?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/