linux-kernel - Re: [PATCH] kvm: handle last_boosted

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4FF26765.5040508@linux.vnet.ibm.com>
Date:	Tue, 03 Jul 2012 09:00:45 +0530
From:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
To:	Rik van Riel <riel@...hat.com>, "Vinod, Chegu" <chegu_vinod@...com>
CC:	Andrew Jones <drjones@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Srikar <srikar@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	KVM <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...hat.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] kvm: handle last_boosted_vcpu = 0 case

On 07/02/2012 08:19 PM, Rik van Riel wrote:
> On 06/28/2012 06:55 PM, Vinod, Chegu wrote:
>> Hello,
>>
>> I am just catching up on this email thread...
>>
>> Perhaps one of you may be able to help answer this query.. preferably
>> along with some data. [BTW, I do understand the basic intent behind
>> PLE in a typical [sweet spot] use case where there is over
>> subscription etc. and the need to optimize the PLE handler in the host
>> etc. ]
>>
>> In a use case where the host has fewer but much larger guests (say
>> 40VCPUs and higher) and there is no over subscription (i.e. # of vcpus
>> across guests<= physical cpus in the host and perhaps each guest has
>> their vcpu's pinned to specific physical cpus for other reasons), I
>> would like to understand if/how the PLE really helps ? For these use
>> cases would it be ok to turn PLE off (ple_gap=0) since is no real need
>> to take an exit and find some other VCPU to yield to ?
>
> Yes, that should be ok.

I think this should be true when we have ple_window tuned to correct
value for guest. (same what you raised)

But otherwise, IMO, it is a very tricky question to answer. PLE is
currently benefiting even flush_tlb_ipi etc apart from spinlock. Having
a properly tuned value for all types of workload, (+load) is really
complicated.
Coming back to ple_handler, IMHO, if we have slight increase in
run_queue length, having directed yield may worsen the scenario.

(In the case Vinod explained, even-though we will succeed in setting
other vcpu task as next_buddy, caller itself gets scheduled out, so
ganging effect reduces. on top of this we always have a question, have 
we chosen right guy OR a really bad guy for yielding.)

>
> On a related note, I wonder if we should increase the ple_gap
> significantly.

Did you mean ple_window?

>
> After all, 4096 cycles of spinning is not that much, when you
> consider how much time is spent doing the subsequent vmexit,
> scanning the other VCPU's status (200 cycles per cache miss),
> deciding what to do, maybe poking another CPU, and eventually
> a vmenter.
>
> A factor 4 increase in ple_gap might be what it takes to
> get the amount of time spent spinning equal to the amount of
> time spent on the host side doing KVM stuff...
>

I agree, I am experimenting with all these things left and right, along
with several optimization ideas I have. Hope to comeback on the
experiments soon.

--
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/