Linux (real-time) scheduling help

[micke_b]

---

Hi, I need a confirmation that I got this right:

1. A thread gets created and put on a run queue, put there by class specific enqueue_task(), correct?

2. schedule() then picks this thread(assuming it is the best one), by calling the class specific pick_next() function and then switches it on the CPU, correct?

3. when the thread is on the CPU one of two things can happen assuming that it always have work to do, preemption or blocked, correct?

4. if the thread gets blocked the class specific dequeue_task() will be called and put it on a sleep queue, correct?

5. if the thread gets preempted the class specific function check_preempt_curr() will be called and the thread gets put back on its run queue, correct?

In the function check_preempt_curr_rt() I'm a little confused. Linux priorities ranges from 1-140 where 1 is the "highest" but the real-time priorities ranges from 1-99 where 99 is the highest? Is this correct? And p->prio in check_preempt_curr_rt() is the priority ranging from 1-140 with 1 highest right? and p->rt_prioirty is rt-prio ranging from 1-99, with 99 highest?

static void check_preempt_curr_rt(struct rq *rq, struct task_struct *p)
{
    if (p->prio < rq->curr->prio) {
        resched_task(rq->curr);
    }
}

With this assumptions p is preempting rq->curr right? that is p gets ON the CPU and rq-curr gets OFF the CPU?

[brahan_7]

Hello,

The code logic looks decieving but I think that the check is designed to ensure that the realtime process is not preemted by another process...
Therefore, it checks to see if a process with a lower priority number has taken cpu time and if so it reschedules the real time process so that it can get back on the cpu...

[micke_b]

I'm not sure if Im buying that, I mean a real-time thread must also be able to preempt another real-time thread if is has higher prioirty ....

[brahan_7]

Ok...I had to check my reference...

In real time processing 1 is the highest priority and 99 is the lowest priority, (this is according to the 3rd edition of Understanding the Linux kernel), you had that backwards...

So the subroutine is giving the next process 'p' cpu time if its priority is over the current one 'rq->curr->prio'.

However, processes have two different states...Active and Expired...if a process is active it is runnable until its time quantum is exhausted, (being runnable doesn't mean its running...it could be waiting but still active). Expired processes have to wait for active processes to expire before they are aloud anymore cpu time. (Basically there are two different tiers of scheduling) The catch is that realtime processes are always set to active...so they can only be preempted by other realtime processes of higher priority, which you already knew, but they cannot be preempted by conventional processes.

I think that answers your question

Check out Understanding the Linux Kernel:
O'Reilly Media | Understanding the Linux Kernel

[brahan_7]

Out of curiosity, what source file can that subroutine be found in?

[micke_b]

Its found in sched_rt.c in the [your kernel]/kernel folder I used kernel 2.6.23.12

Hmm, but when I make a real-time thread with prioirty 90 it will preempt a real-time thread with prioirty 80. This dosen't make any sense to me?

And in POSIX realtime priorities, the highest is the highets number, and Linux are suppose to support POSIX real-time priorities?

But I think there is a different between a tasks "prio" and "rt_prioriy" I think "prio" is the Linux own priority 1-140 with 1 beeing highest. And rt_prioirty is the POSIX version 1-99 with 99 highest. These maps 99-1(rt_priority) ro 1-99(prio) and 100-140 are non real-time prioirties.

Or am I just very confused?

[brahan_7]

Im assuming these threads are within the same kernel process. Give an example of how you create these threads...

[micke_b]

Like this:

static int sched_sp_socket_priority;

int main(void){
  pthread_t ptid;
  struct sched_param sp;
  sched_sp_socket_priority = sched_get_priority_max(SCHED_FIFO);
  if((pthread_create(&ptid, NULL, socket_thread, NULL))) {
    perror("socket thread");
  }
  sp.sched_priority = sched_sp_socket_priority;
  if(pthread_setschedparam(ptid, SCHED_FIFO, &sp)) {
    perror("1. pthread_setschedparam failed!");
    return -1;
  }
}

This thread will preempt other threads created in the same process, and sp.sched_priority is 99.

sched_sp_socket_priority = sched_get_priority_max(SCHED_FIFO);

returns 99.

[brahan_7]

You are using 'SCHED_FIFI', which I'm sure you know means First In First Out, this is different from 'SCHED_OTHER' which would be the kernel default way of scheduling the threads, 1 being highest priority and 99 being lowest priority, to stay within 1 - 140...

if you were to say:

sched_get_priority_max(SCHED_OTHER);

you should get 0 and
if you said:

sched_get_priority_max(SCHED_OTHER);

you should get 0 also because the kernel handles the priorities...

So, using 'SHED_FIFO' or 'SHED_RR' you have min/max | 1/99 priorities for those threads within the process that you created...

You basically figured it out...

You need to make sure that 'check_preempt_curr_rt( )' is using the same kind of sched mechanism (FIFO, RR, OTHER) that you are using when you create the process.

Google SCHED_FIFO...you can find documentation for sched mechanisms.

Does that help at all?

[brahan_7]

Out of curiosity again...what are you trying to create that uses real-time threading?