From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933898Ab0BYVnl (ORCPT ); Thu, 25 Feb 2010 16:43:41 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:47914 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933698Ab0BYVnk (ORCPT ); Thu, 25 Feb 2010 16:43:40 -0500 Subject: Re: [PATCH 0/3] sched: use EDF to throttle RT task groups v2 From: Peter Zijlstra To: Fabio Checconi Cc: Ingo Molnar , Thomas Gleixner , Paul Turner , Dario Faggioli , Michael Trimarchi , Dhaval Giani , Tommaso Cucinotta , linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 25 Feb 2010 21:28:16 +0100 Message-ID: <1267129696.22519.556.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2010-02-23 at 19:56 +0100, Fabio Checconi wrote: > This patchset introduces a group level EDF scheduler extending the > throttling mechanism, in order to make it support generic period > assignments. With this patch, the runtime and period parameters > can be used to specify arbitrary CPU reservations for RT tasks. > > From the previous post [1] I've integrated Peter's suggestions, using > a multi-level hierarchy to do admission control, but a one-level only > equivalent hierarchy for scheduling, and I've not removed the bandwidth > migration mechanism, trying to adapt it to EDF scheduling. In this > version tasks are still inserted into priority arrays and only groups > are kept in a per-rq edf tree. > > The main design issues involved: > > - Since it is not easy to mix tasks and groups on the same scheduler > queue (tasks have no deadlines), the bandwidth reserved to the tasks > in a group is controlled with two additional cgroup attributes: > rt_task_runtime_us and rt_task_period_us. These attributes control, > within a cgroup, how much bandwidth is reserved to the tasks it > contains. The old attributes, rt_runtime_us and rt_period_us, are > still there, and control the bandwidth assigned to the cgroup. They > are used only for admission control. > > - Shared resources are still handled using boosting. When a group > contains a task inside a critical section it is scheduled according > the highest priority among the ones of the tasks it contains. > In this way, the same group has two modes: when it is not boosted > it is scheduled according to its deadline; when it is boosted, it > is scheduled according its priority. Boosted groups are always > favored over non-boosted ones. > > - Given that the various rt_rq's belonging to the same task group > are activated independently, there is the need of a timer per > each rt_rq. > > - While balancing the bandwidth assigned to a cgroup on various cpus > we have to make sure that utilization for the rt_rq's on each cpu > does not exceed the global utilization limit for RT tasks. > > As usual, feedback welcome. Looks very nice, good work! comments in individual replies.