Re: [BUG] cpu-hotplug: Can't offline the CPU with naughty realtime processes

[Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>]

At Tue, 8 May 2007 22:18:50 +0530,
Srivatsa Vaddagiri wrote:
> 
> On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
> > Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
> > and the meaning of each entry is as follows, I think.
> > 
> > +-----------+-----------------------------------------------+
> > | index     | usage                                         |
> > +-----------+-----------------------------------------------+
> > | 0 - 98    | RT processes are here. They are in the entry  |
> > |           | whose index is 99 - sched_priority.           |
> 
> >From sched.h:
> 
> /*
>  * Priority of a process goes from 0..MAX_PRIO-1, valid RT
>  * priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
>  * tasks are in the range MAX_RT_PRIO..MAX_PRIO-1.
> 
> so shouldn't the index for RT processes be 0 - 99, given that
> MAX_RT_PRIO = 100?

However `man sched_priority' says...


       Processes scheduled with SCHED_OTHER or SCHED_BATCH  must
       be assigned the  static  priority  0. Processes  scheduled
       under  SCHED_FIFO  or SCHED_RR can have a static priority
       in the range 1 to 99. The  system calls
       sched_get_priority_min() and sched_get_priority_max() can
       be used to find out the valid priority range for a
       scheduling policy in a portable way on all POSIX.1-2001
       conforming systems.


and see the kernel/sched.c ...


  int sched_setscheduler(struct task_struct *p, int policy,
                         struct sched_param *param)
  {
          ...
          /*
           * Valid priorities for SCHED_FIFO and SCHED_RR are
           * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_NORMAL and
           * SCHED_BATCH is 0.
           */
          if (param->sched_priority < 0 ||
              (p->mm && param->sched_priority > MAX_USER_RT_PRIO-1) ||
              (!p->mm && param->sched_priority > MAX_RT_PRIO-1))
                  return -EINVAL;
          if (is_rt_policy(policy) != (param->sched_priority != 0))
                  return -EINVAL;
          ...
  }


So, if I want to set the rt_prio of a kernel_thread, we can't use this
entry unless set t->prio to 99 directly. I don't know whether we are
allowed to write such code bipassing sched_setscheduler(). In addition,
even if kernel_thread can use this index , I can't understand it's usage.
It can only be used by kernel, but its priority is LOWER than any real
time thread.

If the rule can be changed to the following...

+-----------+-----------------------------------------------+
| index     | usage                                         |
+-----------+-----------------------------------------------+
| 0         | RT processes are here. Only kernel can use    |
|           | this entry.                                   |
+-----------+-----------------------------------------------+
| 1 - 99    | RT processes are here. They are in the entry  |
|           | whose index is 99 - sched_priority.           |
+-----------+-----------------------------------------------+
| 100 - 139 | Ordinally processes are here. They are in the |
|           | entry whose index is (nice+120) +/- 5         |
+-----------+-----------------------------------------------+

... there will be an entry only used by kernel and its priority is HIGHER
than any user process, and I'll get happy :-)

Thanks,

Satoru

> 
> > +-----------+-----------------------------------------------+
> > | 99        | No one use it? CMIIW.                         |
> > +-----------+-----------------------------------------------+
> > | 100 - 139 | Ordinally processes are here. They are in the |
> > |           | entry whose index is (nice+120) +/- 5         |
> > +-----------+-----------------------------------------------+
> > 
> > What's the purpose of the prio_array[99]? Once I exlore source tree
> > briefly and can't found any kernel thread which uses this entry.
> > Does anybody know?
> 
> -- 
> Regards,
> vatsa
-
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/