linux-kernel - Re: [RFC][PATCH] sched/rt: Use IPI to trigger RT task push migration instead of pulling

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 5 Feb 2015 11:55:01 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Clark Williams <williams@...hat.com>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH] sched/rt: Use IPI to trigger RT task push
 migration instead of pulling

On Thu, 5 Feb 2015 16:21:44 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> So can't we flip the problem around; 99 overloaded cpus and 1 going
> 'low', then we IPI the 99, and they're all going to try and push their
> tasks on the one (now) sad cpu?
> 

Ug, you're right :-/

OK, then we could do this, because if there's 10 CPUS with overloaded
RT tasks (more than one queued), and 20 CPUs drop prios, if they all
send to one CPU to do a pull, it will miss pulling from the other CPUs.

But we do not want to send to all CPUS with overloaded RT queues,
because, as you say, they could all try to push to the same queue and
we hit the same problem this patch is trying to solve (lots of CPUs
grabbing the same rq lock).

Thus, we could proxy it.

Send an IPI to just one CPU. When that CPU receives it, it pushes off
only one task (as only one CPU told it it lowered its CPU).

If it receives the IPI and there's no tasks to push, it means that a
there was another CPU that lowered its priority and asked this CPU to
push a task to it. But another CPU got there first. Then this CPU could
check to see if there's another rq out there with overloaded CPUs and
send the IPI to that one. This way, only one CPU is pushing its tasks
off at a time, and we only push if it is likely to succeed.

Pass the IPI around!

Something to work on.

-- Steve

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