lkml.org 
[lkml]   [2008]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 7/8] sched: non-zero lag renice
Peter Zijlstra wrote:
> On Fri, 2008-10-24 at 11:47 -0600, Chris Friesen wrote:
>> Peter Zijlstra wrote:
>>
>> > Then renicing, esp when lowering nice value (getting heavier), its possible
>> > to get into a starvation scenario. If you got too much runtime as a very
>> > light task, you get shot way far too the right, which means you'll have to
>> > wait for a long time in order to run again.
>> >
>> > If during that wait you get reniced down, fairness would suggest you get run
>> > earlier, because you deserve more time.
>> >
>> > This can be solved by scaling the vruntime so that we keep the real-time
>> > lag invariant.
>>
>> If we've already been shot way out to the right, presumably that would give us
>> a large real-time lag. If we renice to a lower nice level, wouldn't we want
>> to reduce the real-time lag rather than make it constant?

Sorry, the patches arrived out of order and my comments were sent out before
reading your definition of "lag" as "the difference between the service time
received from the ideal model and the actual scheduler".

I was using a definition of lag as "amount of time before the process gets
scheduled again".

Given your definition, I think the patch makes sense.

Chris


\
 
 \ /
  Last update: 2008-10-24 23:17    [W:0.047 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site