linux-kernel - Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock

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: <4EA8690C.1040209@goop.org>
Date:	Wed, 26 Oct 2011 13:09:48 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Avi Kivity <avi@...hat.com>
CC:	Raghavendra K T <raghukt@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	"H. Peter Anvin" <hpa@...or.com>, Gleb Natapov <gleb@...hat.com>,
	Virtualization <virtualization@...ts.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	x86@...nel.org, KVM <kvm@...r.kernel.org>,
	Dave Jiang <dave.jiang@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Xen <xen-devel@...ts.xensource.com>,
	Sedat Dilek <sedat.dilek@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Rik van Riel <riel@...hat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Suzuki Poulose <suzuki@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support
 pv-ticketlock

On 10/26/2011 03:34 AM, Avi Kivity wrote:
> On 10/25/2011 08:24 PM, Raghavendra K T wrote:
>> So then do also you foresee the need for directed yield at some point,
>> to address LHP? provided we have good improvements to prove.
> Doesn't this patchset completely eliminate lock holder preemption?

Well, there's the question of whether its better for someone waiting for
a contended lock to just go to sleep and rely on the scheduler to give
CPU time to whoever currently has the lock, or if the scheduler needs a
little hint to boost the lock holder by giving it the waiter's timeslice.

I tend to prefer the former, since there's no reason to suppose that the
the lock holder vcpu is necessarily the scheduler's top priority, and it
may want to schedule something else anyway.

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