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, 04 Jun 2012 17:33:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Cc:	Mike Galbraith <efault@....de>,
	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

On Mon, 2012-06-04 at 20:55 +0530, Srivatsa Vaddagiri wrote:
> * Peter Zijlstra <peterz@...radead.org> [2012-06-04 17:21:11]:
> 
> > That is not to say you couldn't contrive a scenario where it would be
> > needed.. 
> 
> Right ..what if B0. B1 are pinned? !! I think most of the current
> weakness lies in handling tasks that have affinity set.

Yeah, affinity is a pain.. the whole group_imb crap is due to that as
well.

Now I'm not as opposed to this as Mike is, the load cpu_power thing can
also happen due to excessive IRQ time, and hopefully we'll get to have
an unpriv. SCHED_DEADLINE at some point as well.

But we should try to keep the stuff reasonably sane and very much
consider the worst case compute time of the load-balancer. All that redo
logic can be triggered on purpose.

Thing is, you can create an arbitrary hard problem by creating lots of
tasks with tricky masks, we shouldn't bend over backwards trying to
solve it just because.

[ Also, I suspect I wrecked the ALL_PINNED muck, shouldn't we reset
env.loop_break? ]

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