From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57682 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POBlu-0002jE-DC for qemu-devel@nongnu.org; Thu, 02 Dec 2010 11:12:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POBlh-0007ne-Oz for qemu-devel@nongnu.org; Thu, 02 Dec 2010 11:12:38 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]:52170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POBlh-0007nN-MO for qemu-devel@nongnu.org; Thu, 02 Dec 2010 11:12:25 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB2G2u5P006220 for ; Thu, 2 Dec 2010 11:04:22 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0FB11628016 for ; Thu, 2 Dec 2010 10:28:28 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB2FSQEh1663202 for ; Thu, 2 Dec 2010 10:28:27 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB2FSPtE009164 for ; Thu, 2 Dec 2010 13:28:26 -0200 Date: Thu, 2 Dec 2010 20:58:20 +0530 From: Srivatsa Vaddagiri Message-ID: <20101202152819.GB16411@linux.vnet.ibm.com> References: <20101201172953.GF8073@linux.vnet.ibm.com> <1291225502.32004.1787.camel@laptop> <20101201180040.GH8073@linux.vnet.ibm.com> <1291230582.32004.1927.camel@laptop> <4CF76440.30500@redhat.com> <20101202114700.GA18445@linux.vnet.ibm.com> <4CF793FF.4010504@redhat.com> <20101202131312.GC18445@linux.vnet.ibm.com> <4CF7A3F8.1010802@redhat.com> <20101202152716.GA16411@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202152716.GA16411@linux.vnet.ibm.com> Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2) Reply-To: vatsa@linux.vnet.ibm.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Zijlstra , kvm@vger.kernel.org, Mike Galbraith , qemu-devel@nongnu.org, Chris Wright , Anthony Liguori Actually CCing Rik now! On Thu, Dec 02, 2010 at 08:57:16PM +0530, Srivatsa Vaddagiri wrote: > On Thu, Dec 02, 2010 at 03:49:44PM +0200, Avi Kivity wrote: > > On 12/02/2010 03:13 PM, Srivatsa Vaddagiri wrote: > > >On Thu, Dec 02, 2010 at 02:41:35PM +0200, Avi Kivity wrote: > > >> >> What I'd like to see in directed yield is donating exactly the > > >> >> amount of vruntime that's needed to make the target thread run. > > >> > > > >> >I presume this requires the target vcpu to move left in rb-tree to run > > >> >earlier than scheduled currently and that it doesn't involve any > > >> >change to the sched_period() of target vcpu? > > >> > > > >> >Just was wondering how this would work in case of buggy guests. Lets say that a > > >> >guest ran into a AB<->BA deadlock. VCPU0 spins on lock B (held by VCPU1 > > >> >currently), while VCPU spins on lock A (held by VCPU0 currently). Both keep > > >> >boosting each other's vruntime, potentially affecting fairtime for other guests > > >> >(to the point of starving them perhaps)? > > >> > > >> We preserve vruntime overall. If you give vruntime to someone, it > > >> comes at your own expense. Overall vruntime is preserved. > > > > > >Hmm ..so I presume that this means we don't affect target thread's position in > > >rb-tree upon donation, rather we influence its sched_period() to include > > >donated time? IOW donation has no effect on causing the target thread to run > > >"immediately", rather it will have the effect of causing it run "longer" > > >whenever it runs next? > > > > No. The intent (at least mine, maybe Rik has other ideas) is to > > CCing Rik now .. > > > move some vruntime from current to target such that target would be > > placed before current in the timeline. > > Well ok, then this is what I had presumed earlier (about shifting target towards > left in rb-tree). > > > >Even that would require some precaution in directed yield to ensure that it > > >doesn't unduly inflate vruntime of target, hurting fairness for other guests on > > >same cpu as target (example guest code that can lead to this situation > > >below): > > > > > >vcpu0: vcpu1: > > > > > > spinlock(A); > > > > > >spinlock(A); > > > > > > while(1) > > > ; > > > > > > spin_unlock(A); > > > > directed yield should preserve the invariant that sum(vruntime) does > > not change. > > Hmm don't think I understand this invariant sum() part. Lets take a simple > example as below: > > > p0 -> A0 B0 A1 > > p1 -> B1 C0 C1 > > A/B/C are VMs and A0 etc are virtual cpus. p0/1 are physical cpus > > Let's say A0/A1 hit AB-BA spin-deadlock (which one can write in userspace > delibrately). When A0 spins and exits (due to PLE) what does its directed yield > do? Going by your statement, it can put target before current, leading to > perhaps this arrangement in runqueue: > > p0 -> A1 B0 A0 > > Now A1 spins and wants to do a directed yield back to A0, leading to : > > p0 -> A0 B0 A1 > > This can go back and forth, starving B0 (iow leading to some sort of DoS > attack). > > Where does the "invariant sum" part of directed yield kick in to avoid such > nastiness? > > - vatsa