I don't agree with this. BH's are quite different from a run
queue. For one thing, a run queue is a circular list of work to be
done, where jobs may be moved to the back of the list, but the job
remains pending.
A BH, on the other hand, is a singly linked list of one-off jobs. Each
job is removed as it is processed.
Also, another distinction is that BH's are unrelated to processes. The
jobs on a run queue put the kernel into a different state (process)
whereas a BH doesn't.
> Adding another one for RT tasks won't be a problem, all we
> have to do is make sure that the highest-priority RT task
> is up front (this shouldn't be hard as a proper RT system
> doesn't have more than 1 RT task on the queue, because of
> that the overhead will be absolutely minimal).
I don't think a BH paradime for RT processes is the right approach. A
separate run queue is the natural place, IMHO.
A real system could well have more than one RT process on the run
queue. Imagine a lower priority RT thread gets interrupted and the
device driver unblocks a higher priority RT thread. That's already two
on the run queue.
Many RT applications will have multiple threads. While most *will* be
sleeping at any one time, sometimes you're going to get more than on
on the run queue. Here I agree with Larry that a sensible (RT)
application should avoid having lots of threads on the run queue. This
is because RT applications care about latency, so having lots of RT
processes on the run queue is not sensible.
Where I disagree with Larry is that normal user applications will only
have a few processes on the run queue. These applications care less
for latency. Performance is often sacrificed for ease of
implementation (like that 50+ man-year project I mentioned). RT
applications are in a different class than normal user applications,
and many of the design principles are different.
> > To get to your other point: general improvements to the scheduler, I'm
> > not sure what you have in mind. It looks pretty good already. Apart
> > from the RT/long run queue latency issue, the only things that
> > occurred to me is the recalculation of counters. This walks the entire
> > process table. It would be nice to be able to avoid that.
>
> We need to change 3 things in order to implement that:
> - add a sleep_time to the task struct, upon removal from
> the run queue, a p->sleep_time = jiffies is performed
> - add_to_runqueue() has to be modified in order to give
> the process back one priority point for each jiffie it
> slept, up to a maximum of p->priority (maybe this should
> be divided by the system load or by DEF_PRIORITY/p->priority???)
> - the recalculation stuff has to be changed to only recalculate
> the tasks on the run queue.
Can you avoid the division operation? This is particularly painful on
lesser CPUs. Even a multiplication should be avoided.
Regards,
Richard....
-
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/