linux-kernel - Re: [PATCH] sched: balance_cpu to consider other cpus in its group as target of (pinned) task migration

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]

Date:	Mon, 4 Jun 2012 18:37:41 +0530
From:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
To:	Mike Galbraith <efault@....de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Prashanth Nageshappa <prashanth@...ux.vnet.ibm.com>,
	mingo@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	roland@...nel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: balance_cpu to consider other cpus in its group
 as target of (pinned) task migration

* Mike Galbraith <efault@....de> [2012-06-04 14:47:43]:

> You need a good reason to run RT, and being able to starve others to
> death ain't it, so I don't see a good reason to care about the 95% case
> enough to fiddle with load balancing to accommodate the oddball case.

While starvation of SCHED_OTHER task was an extreme case, the point
remains that SCHED_OTHER tasks are better served by moving them away
from cpus running rt tasks that are partially cpu intensive. While the
current code has the nuts and bolts to recognize this situation
(scale_rt_power), it fails to effect SCHED_OTHER task movement because of how
one cpu from a sched_group is designated to pull tasks on behalf of its
siblings and that chosen balance_cpu may not be in the task's cpus_allowed mask
(but the task can run on one or more of its sibling cpus).

- vatsa

--
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/