linux-kernel - SCHED_RR vs push-pull

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-next>] [day] [month] [year] [list]

Date:	Fri, 11 Dec 2015 15:10:28 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Juri Lelli <juri.lelli@...il.com>,
	Luca Abeni <luca.abeni@...tn.it>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: SCHED_RR vs push-pull

Hai,

Thomas just reported a 'fun' problem with our rt 'load-balancer'.

The problem is 2 cpus 4 equal prio RR tasks.
Suppose an unequal distribution of these tasks among the CPUs; eg 1:3.

Now one would expect; barring other constraints; that each CPU would get
2 of the tasks and they would RR on their prio level.

This does not happen.

The push-pull thing only acts when there's idle or new tasks, and in the
above scenario, the CPU with only the single RR task will happily
continue running that task, while the other CPU will have to RR between
the remaining 3.

Now my initial thoughts were to define a global RR order using a
virtual timeline and you'll get something like EEVDF on a per RR prio
level with push-pull state between that.

Which might be a tad over engineered.

Is there a 'sane' solution to this problem? One that still is
deterministic, because this is after all, RT scheduling.

Happy thinking ;-)
--
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/