Increasing HZ:
- makes for greater overhead in handling the timer interrupt
- doesn't decrease the latency RT tasks are experiencing
> > B: The evidence for a second run queue solving the problem is very
> > strong. The numbers I've posted show beyond any doubt that an
> > increased run queue length has a measurable effect on context switch
> > latency.
>
> I must have missed these results. What I saw were microbenchmark results
> with no kernel profiling and no explanation. Why should searching a
> queue of 10 on 586 take any significant time? Where is the time spent?
There is only one place where it _can_ be spent (the scheduler
is quite simple) and that is at scanning the run_queue.
> > I'm not talking about overall system performance. I'm talking about
> > the effect of increased latency on latency-sensitive RT
> > applications. This is a different world.
>
> I'm very skeptical of loose use of the term RT. Are these tasks of yours
> really RT? Hard? Soft? Statistical?
They are fairly hard and are triggered from an interrupt. After
the interrupt enters the machine, the RT tasks should respond
as fast as possible. There's a certain area where processes and
device drivers meet, that is the field we're talking about.
> > Also, a separate RT run queue would make the scheduler code simpler
> > and more robust.
>
> How? It's quite simple as it is.
Reducing overall simplicity is not the goal. The main goal
is to reduce the scheduler latency for _RT_ tasks. If this
means we have to code up a completely new (extra-extra-short)
path for RT tasks that's OK.
We can probably cut the time for add_to_runqueue() and
related things by more than half for RT tasks. This can
be done because:
- we need to check less things for RT tasks (they don't
have a dynamic priority) --> quite a large gain.
- if we put RT tasks in their own runqueue, we don't even
have to walk the normal runqueue --> another few uS gained
If this process slows the scheduler path for normal processes,
well, who cares? Normal processes don't need this latency.
The point is to cut down latency for cases where it really
matters and to have something reasonably fast and fancy for
stuff where fancy stuff might help (timeslicing processes,
the load-independant recharging _really_ helps :).
> > Go back to an early post of mine where I suggest a separate RT run
> > queue as a possible 2.3 project. I didn't say "let's do this for 2.2".
Why not? It can probably be done in under 15 lines of (recycled!)
code. As long as we don't introduce new code to the kernel, we
can add stuff now.
Let's see what's involved:
- adding a new add_to_runqueue path for RT tasks. since they don't
have dynamic priority, we can sort them by priority
- this in turn means we can leave out goodness() for RT tasks, we
simply pick the first process on the queue (as that will be the
one with the highest priority)
- we need to add this check to the scheduler:
if (rt_queue->next != rt_queue) switch_to(rt_queue->next);
When that is done, we can chainsaw the RT stuff from
goodness(), add_to_runqueue() and reschule_idle(), giving
a shorter code path for normal tasks as well.
This certainly looks like a worthwhile effort to me...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/