lkml.org 
[lkml]   [2004]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Likelihood of rt_tasks

* Con Kolivas <kernel@kolivas.org> wrote:

> 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.

very much so. This is (sub-)nanoseconds stuff, while the scheduling
latencies are tens of milliseconds or more - at least 7 orders of
magnitude difference.

the unlikely() check in rt_task() was mainly done because there was a
steady stream of microoptimizations that added unlikely() to rt_task().
So now we do in everywhere and have removed the unlikely()/likely()
branches from sched.c. It doesnt really matter in real-world terms, but
it will make the common case code (non-RT) a tiny bit more compact. And
i challenge anyone to be able to even measure the difference to an RT
task.

Not to mention that any truly RT-centric/embedded distribution would
compile the kernel for size anyway, at which point the compiler ignores
(or should ignore) the likely/unlikely attributes anyway. So there's
really no harm to anyone and the code got a bit more readable.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.117 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site