From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35047 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNs3T-0007Kx-C1 for qemu-devel@nongnu.org; Wed, 01 Dec 2010 14:09:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNs3O-0002lz-EP for qemu-devel@nongnu.org; Wed, 01 Dec 2010 14:09:27 -0500 Received: from casper.infradead.org ([85.118.1.10]:36633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNs3O-0002ll-88 for qemu-devel@nongnu.org; Wed, 01 Dec 2010 14:09:22 -0500 From: Peter Zijlstra In-Reply-To: <20101201180040.GH8073@linux.vnet.ibm.com> References: <1290530963-3448-1-git-send-email-aliguori@us.ibm.com> <4CECCA39.4060702@redhat.com> <4CED1A23.9030607@linux.vnet.ibm.com> <4CED1FD3.1000801@redhat.com> <20101201123742.GA3780@linux.vnet.ibm.com> <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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Dec 2010 20:09:42 +0100 Message-ID: <1291230582.32004.1927.camel@laptop> Mime-Version: 1.0 Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: vatsa@linux.vnet.ibm.com Cc: Mike@gnu.org, kvm@vger.kernel.org, Galbraith , qemu-devel@nongnu.org, Chris Wright , Anthony Liguori , Avi Kivity On Wed, 2010-12-01 at 23:30 +0530, Srivatsa Vaddagiri wrote: > On Wed, Dec 01, 2010 at 06:45:02PM +0100, Peter Zijlstra wrote: > > On Wed, 2010-12-01 at 22:59 +0530, Srivatsa Vaddagiri wrote: > > >=20 > > > yield_task_fair(...) > > > { > > >=20 > > > + ideal_runtime =3D sched_slice(cfs_rq, curr); > > > + delta_exec =3D curr->sum_exec_runtime - curr->prev_sum_exec_r= untime; > > > + rem_time_slice =3D ideal_runtime - delta_exec; > > > + > > > + current->donate_time +=3D rem_time_slice > some_threshold ? > > > + some_threshold : rem_time_slice; > > >=20 > > > ... > > > } > > >=20 > > >=20 > > > sched_slice(...) > > > { > > > slice =3D ... > > >=20 > > > + slice +=3D current->donate_time; > > >=20 > > > } > > >=20 > > > or something close to it. I am bit reluctant to go that route myself,= unless the > > > fairness issue with plain yield is quite bad.=20 > >=20 > > That really won't do anything. You need to adjust both tasks their > > vruntime. >=20 > We are dealing with just one task here (the task that is yielding). > After recording how much timeslice we are "giving up" in current->donate_= time > (donate_time is perhaps not the right name to use), we adjust the yieldin= g > task's vruntime as per existing logic (for ex: to make it go to back of > runqueue). When the yielding tasks gets to run again, lock is hopefully= =20 > available for it to grab, we let it run longer than the default sched_sli= ce() > to compensate for what time it gave up previously to other threads in sam= e > runqueue. This ensures that because of yielding upon lock contention, we = are not > leaking bandwidth in favor of other guests. Again I don't know how much o= f > fairness issue this is in practice, so unless we see some numbers I'd pre= fer > sticking to plain yield() upon lock-contention (for unmodified guests tha= t is). No, that won't work. Once you've given up time you cannot add it back without destroying fairness. You can limit the unfairness by limiting the amount of feedback, but I really dislike such 'yield' semantics.