lkml.org 
[lkml]   [2007]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BUG] cpu-hotplug: Can't offline the CPU with naughty realtime processes
    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/

    \
     
     \ /
      Last update: 2007-05-09 02:45    [W:0.029 / U:61.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site