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
| ||
|
Date: Fri, 17 Dec 2010 17:09:24 +0200 From: Avi Kivity <avi@...hat.com> To: Mike Galbraith <efault@....de> CC: Rik van Riel <riel@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Chris Wright <chrisw@...s-sol.org> Subject: Re: [RFC -v2 PATCH 2/3] sched: add yield_to function 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. -- 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/
Powered by blists - more mailing lists