Re: Likelihood of rt_tasks

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

Peter Williams wrote:
> Con Kolivas wrote:
> 
>> A quick question about the usefulness of making rt_task() checks 
>> unlikely in sched-unlikely-rt_task.patch which is in -mm
>>
>> quote:
>>
>> diff -puN include/linux/sched.h~sched-unlikely-rt_task 
>> include/linux/sched.h
>> --- 25/include/linux/sched.h~sched-unlikely-rt_task    Fri Jul  2 
>> 16:33:01 2004
>> +++ 25-akpm/include/linux/sched.h    Fri Jul  2 16:33:01 2004
>> @@ -300,7 +300,7 @@ struct signal_struct {
>>
>>  #define MAX_PRIO        (MAX_RT_PRIO + 40)
>>
>> -#define rt_task(p)        ((p)->prio < MAX_RT_PRIO)
>> +#define rt_task(p)        (unlikely((p)->prio < MAX_RT_PRIO))
>>
>>  /*
>>   * Some day this will be a full-fledged user tracking system..
>>
>> ---
>> While rt tasks are normally unlikely, what happens in the case when 
>> you are scheduling one or many running rt_tasks and the majority of 
>> your scheduling is rt? Would it be such a good idea in this setting 
>> that it is always hitting the slow path of branching all the time?
> 
> 
> Even when this isn't the case you don't want to make all rt_task() 
> checks "unlikely".  In particular, during "wake up" using "unlikely" 
> around rt_task() will increase the time that it takes for SCHED_FIFO 
> tasks to get onto the CPU when they wake which will be bad for latency 
> (which is generally important to these tasks as evidenced by several 
> threads on the topic).

Well I dont think making them unlikely is necessary either, but 
realistically the amount of time added by the unlikely() check will be 
immeasurably small in real terms - and hitting it frequently enough will 
be washed over by the cpu as Ingo said. I dont think the order of 
magnitude of this change is in the same universe as the problem of 
scheduling latency that people are complaining of.

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]