Messages in this thread | | | Date | Sat, 10 Jul 2004 10:16:15 +1000 | From | Con Kolivas <> | Subject | Re: Likelihood of rt_tasks |
| |
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 [unhandled content-type:application/pgp-signature] | |