Date: Fri, 11 Dec 2015 15:10:28 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Juri Lelli <juri.lelli@gmail.com>,
        Luca Abeni <luca.abeni@unitn.it>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel@vger.kernel.org
Subject: SCHED_RR vs push-pull
Message-ID: <20151211141028.GH6357@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1171
Lines: 33

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/