Linux에서 가장 높은 우선 순위 인 실시간 우선 순위

Linux에서 가장 높은 우선 순위 인 실시간 우선 순위

---

Linux 실시간 프로세스 우선 순위 범위 1 ~ 99에서 가장 높은 우선 순위 인 1 또는 99가 나에게 명확하지 않습니다.

"Understanding the Linux Kernel"(O'Reilly)의 섹션 7.2.2에서는 1이 가장 높은 우선 순위라고 말하며, 이는 일반 프로세스가 100에서 139까지의 정적 우선 순위를 가지며 100이 가장 높은 우선 순위를 갖는다는 점을 고려할 때 의미가 있습니다.

"모든 실시간 프로세스는 1 (가장 높은 우선 순위)에서 99 (가장 낮은 우선 순위)까지의 값인 실시간 우선 순위와 연관됩니다."

반면에 sched_setscheduler man 페이지 (RHEL 6.1)에서는 99가 가장 높다고 주장합니다.

"실시간 정책 (SCHED_FIFO, SCHED_RR) 중 하나에 따라 스케줄링 된 프로세스는 1 (낮음)에서 99 (높음) 범위의 sched_priority 값을 갖습니다."

실시간 우선 순위가 가장 높은 것은 무엇입니까?

---

다음과 같이이를 확인하기위한 실험을 수행했습니다.

• process1 : RT 우선 순위 = 40, CPU 선호도 = CPU 0.이 프로세스는 10 초 동안 "회전"하므로 우선 순위가 낮은 프로세스가 CPU 0에서 실행되지 않도록합니다.

• process2 : RT 우선 순위 = 39, CPU 선호도 = CPU 0.이 프로세스는 0.5 초마다 stdout에 메시지를 인쇄하고 그 사이에 휴면합니다. 각 메시지와 함께 경과 시간을 인쇄합니다.

PREEMPT_RT 패치로 2.6.33 커널을 실행하고 있습니다.

실험을 실행하기 위해 한 창 (루트)에서 process2를 실행 한 다음 다른 창에서 process1 (루트)을 시작합니다. 결과는 process1이 process2를 선점하는 것으로 보이며 전체 10 초 동안 실행되도록 허용하지 않습니다.

두 번째 실험에서는 process2의 RT 우선 순위를 41로 변경합니다.이 경우 process2는 process1에 의해 선점 되지 않습니다 .

이 실험은 sched_setscheduler ()에서 더 큰 RT 우선 순위 값이 더 높은 우선 순위를 가지고 있음을 보여줍니다 . 이것은 Michael Foukarakis가 sched.h에서 지적한 것과 모순되는 것처럼 보이지만 실제로는 그렇지 않습니다. 에서 sched.c 커널 소스에서, 우리는이 :

static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
        BUG_ON(p->se.on_rq);

        p->policy = policy;
        p->rt_priority = prio;
        p->normal_prio = normal_prio(p);
        /* we are holding p->pi_lock already */
        p->prio = rt_mutex_getprio(p);
        if (rt_prio(p->prio))
                p->sched_class = &rt_sched_class;
        else
                p->sched_class = &fair_sched_class;
        set_load_weight(p);
}

rt_mutex_getprio (p)는 다음을 수행합니다.

return task->normal_prio;

normal_prio ()는 다음을 수행합니다.

prio = MAX_RT_PRIO-1 - p->rt_priority;  /* <===== notice! */
...
return prio;

즉, 우리는 (내 자신의 해석) :

p->prio = p->normal_prio = MAX_RT_PRIO - 1 - p->rt_priority

와! 헷갈리네요! 요약:

• p-> prio를 사용하면 더 작은 값이 더 큰 값을 선점합니다.

• p-> rt_priority를 ​​사용하면 더 큰 값이 더 작은 값을 선점합니다. sched_setscheduler ()를 사용하여 설정 한 실시간 우선 순위입니다.

---

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. Priority
 * values are inverted: lower p->prio value means higher priority.
 *
 * The MAX_USER_RT_PRIO value allows the actual maximum
 * RT priority to be separate from the value exported to
 * user-space.  This allows kernel threads to set their
 * priority to a value higher than any user task. Note:
 * MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
 */

이 부분을 참고하십시오.

우선 순위 값이 반전됩니다. 값이 낮을 p->prio수록 우선 순위가 높습니다 .

---

가장 높은 실시간 우선 순위를 결정하려면 프로그래밍 방식으로 설정할 수 있습니다. sched_get_priority_max 함수를 사용하십시오.

Linux 2.6.32에서 sched_get_priority_max (SCHED_FIFO) 호출은 99를 반환합니다.

http://linux.die.net/man/2/sched_get_priority_max 참조

---

짧은 답변

99는 실시간 우선 순위에서 승자가 될 것입니다.

PR은 우선 순위 수준입니다 (범위 -100 ~ 40). PR이 낮을수록 프로세스의 우선 순위가 높아집니다.

PR은 다음과 같이 계산됩니다.

• 일반 프로세스의 경우 : PR = 20-NI (NI는 좋으며 범위는 -20에서 19까지)
• 실시간 프로세스의 경우 : PR =-1-real_time_priority (real_time_priority 범위는 1에서 99까지)

긴 답변

프로세스에는 일반 프로세스 와 실시간 프로세스의 두 가지 유형이 있습니다. 일반 프로세스 (및 해당 프로세스 에만 해당)의 경우 다음과 같이 nice가 적용됩니다.

좋은

"niceness"척도는 -20에서 19로, -20이 가장 높은 우선 순위이고 19가 가장 낮은 우선 순위입니다. 우선 순위 수준은 다음과 같이 계산됩니다.

PR = 20 + NI

NI는 좋은 수준이고 PR은 우선 순위입니다. 보시다시피 -20은 실제로 0에 매핑되고 19는 39에 매핑됩니다.

기본적으로 프로그램 nice 값은 0 비트입니다. 루트 사용자가 다음 명령을 사용하여 지정된 nice 값으로 프로그램을 점심 식사 할 수 있습니다.

nice -n <nice_value> ./myProgram 

실시간

우리는 더 멀리 갈 수 있습니다. 좋은 우선 순위는 실제로 사용자 프로그램에 사용됩니다. UNIX / LINUX 전체 우선 순위의 범위는 140 개 값이지만 nice 값을 사용하면 프로세스가 범위의 마지막 부분 (100에서 139까지)에 매핑 할 수 있습니다. 이 방정식은 음의 PR 레벨 (-100에서 -1)에 해당하는 0에서 99 사이의 값에 도달 할 수 없도록합니다. 이러한 값에 액세스하려면 프로세스를 "실시간"으로 지정해야합니다.

LINUX 환경에는 다음 명령으로 표시 할 수있는 5 개의 스케줄링 정책이 있습니다.

chrt -m 

다음 목록이 표시됩니다.

1. SCHED_OTHER   the standard round-robin time-sharing policy
2. SCHED_BATCH   for "batch" style execution of processes
3. SCHED_IDLE    for running very low priority background jobs.
4. SCHED_FIFO    a first-in, first-out policy
5. SCHED_RR      a round-robin policy

The scheduling processes could be divided into 2 groups, the normal scheduling policies (1 to 3) and the real time scheduling policies (4 and 5). The real time processes will always have priority over normal processes. A real time process could be called using the following command (The example is how to declare a SCHED_RR policy):

chrt --rr <priority between 1-99> ./myProgram

To obtain the PR value for a real time process the following equation is applied:

PR = -1 - rt_prior

Where rt_prior corresponds to the priority between 1 and 99. For that reason the process which will have the higher priority over other processes will be the one called with the number 99.

It is important to note that for real time processes, the nice value is not used.

To see the current "niceness" and PR value of a process the following command can be executed:

top

Which shows the following output:

In the figure the PR and NI values are displayed. It is good to note the process with PR value -51 that corresponds to a real time value. There are also some processes whose PR value is stated as "rt". This value actually corresponds to a PR value of -100.

---

Your assumption that normal processes have static priorities from 100 to 139 is volatile at best and invalid at worst. What I mean is that: set_scheduler only allows the sched_priority to be 0 (which indicates dynamic priority scheduler) with SCHED_OTHER / SCHED_BATCH and SCHED_IDLE (true as of 2.6.16).

Programmatically static priorities are 1-99 only for SCHED_RR and SCHED_FIFO

Now you may see priorities from 100-139 being used internally by a dynamic scheduler howeve,r what the kernel does internally to manage dynamic priorities (including flipping the meaning of high vs. low priority to make the comparison or sorting easier) should be opaque to the user-space.

Remember in SCHED_OTHER you are mostly stuffing the processes in the same priority queue.

The idea is to make kernel easier to debug and avoid goofy out-of-bound mistakes.

So the rationale in switching the meaning could be that as a kernel developer don't want to use math like 139-idx (just in case idx > 139) ... it is better to do math with idx-100 and reverse the concept of low vs. high because idx < 100 is well understood.

Also a side effect is that niceness becomes easier to deal with. 100 - 100 <=> nice == 0; 101-100 <=> nice == 1; etc. is easier. It collapses to negative numbers nicely as well (NOTHING to do with static priorities) 99 - 100 <=> nice == -1 ...

---

1. Absolutely, the realtime priority is applicable to the RT policies FIFO and RR which varies from 0-99.

2. We do have the 40 as a count of the non real time process priority for BATCH, OTHER policies which varies from 0-39 not from 100 to 139. This, you can observe by looking at any process in the system which is not a realtime process. It will bear a PR of 20 and NIceness of 0 by default. If you decrease the niceness of a process (usually, lower or negative the number lesser the niceness, more hungry the process), say from 0 to -1, you 'll observe that the PRiority will drop to 19 from 20. This simply tells that, if you make a process more hungry or would like to get a little more attention by decreasing the niceness value of the PID you 'll get decrease in priority too, thus lower the PRIORITY number HIGHER the PRIORITY.

   Example:
   
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   2079 admin     10 -10  280m  31m 4032 S  9.6  0.0  21183:05 mgmtd
   [admin@abc.com ~]# renice -n -11 2079
   2079: old priority -10, new priority -11
   [admin@abc.com ~]# top -b | grep mgmtd
   2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
   ^C
   

Hope this practical example clarifies the doubts and may help fix the words at incorrect source, if any.

참고URL : https://stackoverflow.com/questions/8887531/which-real-time-priority-is-the-highest-priority-in-linux