lkml.org 
[lkml]   [2009]   [Sep]   [6]   [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

On 2009-09-06, at 8:09 AM, Mike Galbraith wrote:

> On Sun, 2009-09-06 at 07:53 -0700, Anirban Sinha wrote:
>>
>>
>>
>>> Seems kjournald can end up depending on kblockd/3, which ain't
>>> going anywhere with that 100% RT hog in the way,
>>
>> I think in the past AKPM's response to this has been "just don't do
>> it", i.e, don't hog the CPU with an RT thread.
>
> Oh yeah, sure. Best to run RT oinkers on isolated cpus.

Correct. Unfortunately at some places, the application coders do
stupid things and then the onus falls on the kernel guys to make
things 'just work'.

I would not have any problems if such a cap mechanism did not exist at
all. However, since we do have such a tuning knob. I would say that
let's make it do what it is supposed to do. In the documentation it
says "0.05s to be used by SCHED_OTHER". Unfortunately, it never hints
that if your thread is tied to the RT core, you are screwed. The
bandwidth accumulation logic would virtually kill all the remaining
SCHED_OTHER threads, much before that 95% cap is reached. Somewhere it
doesn't quite seem right. At the very very least, can we have this
clearly written in sched-rt-group.txt?

Cheers,

Ani




\
 
 \ /
  Last update: 2009-09-07 02:45    [W:0.094 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site