lkml.org 
[lkml]   [2009]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: question on sched-rt group allocation cap: sched_rt_runtime_us
From
Date

> Looking at the git history, there have been several bugfixes to the rt
> bandwidth code from 2.6.26, one of them seems to be strictly related
> to
> runtime accounting with your setup:
>
> commit f6121f4f8708195e88cbdf8dd8d171b226b3f858
> Author: Dario Faggioli <raistlin@linux.it>
> Date: Fri Oct 3 17:40:46 2008 +0200
>
> sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq

Hmm. Indeed there did seem to have quite a few fixes to the accounting
logic. I back-patched our 2.6.26 kernel with the upstream patches that
seemed relevant and my test code now yields reasonable results.
Applying the above patch did not fix it though which kind of makes
sense since from the commit log it seems that the patch fixed cases
when the RT task was getting *less* CPU than it's bandwidth allocation
as opposed to more as in my case. I haven't bisected the patchet to
figure out exactly which one fixed it but I intend to do it later just
for fun.

For completeness, these are the results after applying the upstream
patches *and* disabling bandwidth borrowing logic on my 2.6.26 kernel
running on a quad core blade with CONFIG_GROUP_SCHED turned off (100HZ
jiffies):

rt_runtime/
rt_period % of SCHED_OTHER iterations

.40 100%
.50 74%
.60 47%
.70 31%
.80 18%
.90 8%
.95 4%

--Ani




\
 
 \ /
  Last update: 2009-09-08 23:39    [W:0.063 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site