Hello,
I have a system with 2.6.20.7 patched with the v6 CFS patch. I am having

issues (I believe) with fairness in regards to my real-time tasks.

First, let me describe my setup:
* I use the kernel preemption config option.

* I am using an Intel Xeon with Hyperthreading enabled (and using the

SMP config option)

* I have 2 kernel modules -- one that is a device driver (receives

interrupts from a device) but also spawns a thread for processing

messages from kernel module 2. Kernel module 2 controls the hardware and

receives messages from the driver via a message ring. It also puts

messages into a separate ring to control the hardware through the

hardware. I have 4 different threads spawned when I insmod this module.

The 4 threads (call them control threads) all do the same thing (i.e.

there is a thread associated with each port on the device). The threads

will get messages from the driver on behalf of their port and send

control messages back to their port through the driver's message ring,

etc. This may sound complicated but really all I'm doing is abstracting

out the details of controlling the hardware from the control threads and

provide a simple interface (the message rings) for controlling the

hardware and receiving events from it.

* I have given the 4 control threads and the 1 device driver "receive

message" thread MAX_RT_PRIO - 1 priority (with a call to

sched_setscheduler(...).

* As I stated earlier, I use a set of kfifo message rings to communicate

between a control thread and the driver. When the control thread puts a

message into the ring for the driver thread, he calls "up()" on a

semaphore that the driver exported. When the driver puts a message into

the ring for the control thread, he too calls "up()" on a different

semaphore exported by the control thread.

* I expect all 5 threads to be the highest priority tasks in the system

and ALWAYS be scheduled if they are ready (provided that another one of

my 5 RT prio threads isn't already running...
[ message continues ]

Chris,
CFSv6 is *very* old. It was not that bad, but looking back, it has

improved a lot since. You should upgrade to v20.x first, and it's

likely that most of your problems will vanish.
Regards,

willy
-

yeah. I remember we fixed something in the RT task balancing area too,

so chances are that this bug got fixed. The latest backported CFS

version can be picked up from:
    http://people.redhat.com/mingo/cfs-scheduler/
	Ingo

-

Hello,
First, I'm assuming that if I want my task to have the HIGHEST priority

in the system (i.e. preempt any other task whenever it is put into the

ready queue (assuming I have preemption turned on/configured)), I use

sched_setscheduler (...) and use the sched_priority in sched_param for

MAX_RT_PRIO -1. Is this correct?
Second, assuming that MAX_RT_PRIO-1 is the highest, would it be bad on

an SMP/Hyperthreading system (that's using the migration thread

balancing in 2.6.20.7) to set a task's priority to MAX_RT_PRIO -1 given

the fact that the migration threads are already set to MAX_RT_PRIO -1?

Should I be setting my task's prio to MAX_RT_PRIO-2 to not interfere

with the load balancing?
Thanks,

Chris
-

Actually it's probably best to use sched_get_priority_max for the max
The migrate task of a given CPU isn't the only one that will take

tasks off its CPU to push them to others (although it does do that).

But there's other load balancing work going on in the scheduler

(looking at the 2.6.20 sched.c).
Although it would be interesting to see what the result would be if you

had N+1 tasks running on N CPUs all doing busy loops, and make one of

the tasks with the prio of MAX_RT_PRIO-1, and see if we have one task

that is starved and never schedules. But I'm sure this should be fixed

(if it was ever broken) with the latest scheduling work that's being

done in the most recent kernels.
-- Steve
-