From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52445 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PO91K-0001ve-Ss for qemu-devel@nongnu.org; Thu, 02 Dec 2010 08:18:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PO8yN-0007BT-AS for qemu-devel@nongnu.org; Thu, 02 Dec 2010 08:16:22 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:37281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PO8yN-0007BC-7r for qemu-devel@nongnu.org; Thu, 02 Dec 2010 08:13:19 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB2Cth5t005197 for ; Thu, 2 Dec 2010 07:55:43 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8C4BC4DE8039 for ; Thu, 2 Dec 2010 08:11:37 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB2DDHHV185132 for ; Thu, 2 Dec 2010 08:13:17 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB2DDGmY026362 for ; Thu, 2 Dec 2010 06:13:16 -0700 Date: Thu, 2 Dec 2010 18:43:12 +0530 From: Srivatsa Vaddagiri Message-ID: <20101202131312.GC18445@linux.vnet.ibm.com> References: <4CF6460C.5070604@redhat.com> <20101201161221.GA8073@linux.vnet.ibm.com> <1291220718.32004.1696.camel@laptop> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF793FF.4010504@redhat.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 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? 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); - vatsa