From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC -v2 PATCH 2/3] sched: add yield_to function Date: Fri, 17 Dec 2010 17:09:24 +0200 Message-ID: <4D0B7D24.5060207@redhat.com> References: <20101213224434.7495edb2@annuminas.surriel.com> <20101213224657.7e141746@annuminas.surriel.com> <1292306896.7448.157.camel@marge.simson.net> <4D0A6D34.6070806@redhat.com> <1292569018.7772.75.camel@marge.simson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rik van Riel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Srivatsa Vaddagiri , Peter Zijlstra , Chris Wright To: Mike Galbraith Return-path: In-Reply-To: <1292569018.7772.75.camel@marge.simson.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 12/17/2010 08:56 AM, Mike Galbraith wrote: > > Surely that makes it a reasonable idea to call yield, and > > get one of the other tasks on the current CPU running for > > a bit? > > There's nothing wrong with trying to give up the cpu. It's the concept > of a cross cpu yield_to() that I find mighty strange. What's so strange about it? From a high level there are N runnable tasks contending for M cpus. If task X really needs task Y to run, what does it matter if task Y last ran on the same cpu as task X or not? Do I correctly read between the lines that CFS maintains complete fairness only on a cpu, but not globally? I hope I'm wrong, but PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 8648 avi 20 0 106m 1092 148 R 80.4 0.0 0:26.03 1 bash 8656 avi 20 0 106m 1080 136 R 47.3 0.0 0:14.73 0 bash 8652 avi 20 0 106m 1080 136 R 47.0 0.0 0:15.36 0 bash doesn't look too good (three infinite loops in bash started at the roughly same time) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.