linux-kernel - Re: [RFC -v2 PATCH 2/3] sched: add yield

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D0B7D24.5060207@redhat.com>
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/