2012-04-26 15 views
5

Escribí un programa de prueba que consiste en solo un ciclo infinito con algunos cálculos en el interior y no realiza operaciones de E/S. Traté de iniciar dos instancias del programa, una con un alto valor amabilidad , y el otro con un bajo valor de la amabilidad:La configuración de bondad de proceso (prioridad) no tiene ningún efecto en Linux

sudo nice -n 19 taskset 1 ./test 
sudo nice -n -20 taskset 1 ./test 

El comando taskset asegura que ambos programas se ejecutan en el mismo núcleo. Al contrario de lo que esperaba, la parte superior informa que ambos programas obtienen aproximadamente el 50% del tiempo de cálculo . ¿Porqué es eso? ¿El buen comando incluso tiene un efecto?

+0

¿Cuáles fueron los cálculos? Quizás no haya suficiente contención en el procesador para marcar la diferencia – laher

+0

Los cálculos dentro del ciclo son bastante largos. También verifiqué la salida del ensamblador generado y no se optimizó nada (compilado con la configuración de optimización más baja en gcc). –

+0

posible duplicado de [Entender renice] (http://stackoverflow.com/questions/22090126/understanding-renice) – ninjalj

Respuesta

1

Supongo que falta un & al final de la línea de comando. De lo contrario, la segunda línea no se ejecutará hasta que la primera se complete.

Mientras ambos procesos se están ejecutando, utilice algo como top y asegúrese de que cada uno tenga el valor que usted asignó.

¿Qué ocurre si inicia los procesos utilizando solo taskset y luego ajusta su prioridad con renice después de que se estén ejecutando?

+1

El problema era que estaba ejecutando las instancias en dos ventanas de la consola en primer plano. Cuando los ejecuto en segundo plano (usando &) funciona. Parece que Linux privilegia procesos que se ejecutan en primer plano en una consola y en gran parte (¿completamente?) Ignora sus valores de bondad. Esto tiene sentido ya que un usuario probablemente quiera interactuar con el programa que él/ella comenzó en una ventana de consola. –

+0

Cualquier aclaración sobre cómo funciona esto exactamente sería muy apreciada. –

+0

Al ejecutar un programa en primer plano, se ejecuta como un proceso secundario de la consola que lo engendró, y los procesos secundarios suelen heredar la prioridad de sus elementos principales. Agregar el 'y' ejecuta el programa como un proceso completamente separado, lo que le permite controlar su prioridad individualmente. – bta

2

que arme un test.c que sólo lo hace:

for(;;) 
    { 
    } 

y luego corrió con su agradable de. No ejecuté un sudo diferente para cada uno, sino que hice un shell interactivo y los ejecuté desde allí. Usé dos &.

Obtuve uno ./test golpeando mi CPU con fuerza, y una apenas tocándola.

Naturalmente, el sistema todavía se sentía bastante receptivo; Se necesitan muchos procesos de acaparamiento de CPU en procesadores modernos para obtener tanta carga que se puede "sentir".

Esto contrasta con los procesos de acaparamiento de E/S y los procesos de almacenamiento de memoria; en estos casos, un único proceso codicioso puede hacer que un sistema sea doloroso de usar.

Supongo que su sistema tiene una falla (o sutileza) relacionada con la prioridad relativamente única, o hay algo con su metodología.

Ejecuté mi prueba en un sistema Ubuntu 11.04.

+0

Cuando ejecuté ambos procesos en segundo plano, también funcionó. Supongo que Linux privilegia procesos con los que el usuario puede querer interactuar (por ejemplo, programas iniciados desde bash y ejecutándose en primer plano), y en gran medida ignora sus valores de bondad. –

1

Configuración de bondad de proceso (prioridad) ¡TIENE efecto en Linux!(en la práctica, pero sólo si se le da suficiente trabajo que hacer!)

En mi sistema, siempre y cuando todos los núcleos están a plena carga, a continuación, agradable qué tienen un impacto. En ubuntu 14.04, los procesos se ejecutan con nice -N obtiene operaciones 0.807 ** N en comparación con los procesos ejecutados sin alterar el buen valor (dado que está ejecutando una instancia por núcleo para cada nivel agradable).

En mi caso tengo quad-core i7 con Hyper Threading desactivado, por lo que si ejecuto cuatro o menos procesos, entonces no importa cuáles sean sus buenos valores: cada uno obtiene un núcleo completo. Si ejecuto cuatro procesos en el buen nivel 0 y 4 en el buen nivel 12, entonces los que están en el nivel 12 pasan a través de 0.807^12, es decir, aproximadamente el 7% del trabajo que hacen en el buen nivel cero.La proporción parece ser un predictor razonable desde los niveles agradables 0 a 14, después de eso fluctúa (unas pocas ejecuciones tuvieron un buen nivel 18 procesando más que un buen 16, por ejemplo) - Hacer la prueba por más tiempo puede suavizar los resultados.

(rubí 2.1.2 utilizado)

, archivo cl:

uptime 
nices='-0 -6 -12 -18' 
nices='-0 -18' 
nices='-0 -2 -4 -6 -8 -10 -12 -14 -16 -18' 
rm -f ,n-* 
for i in 1 2 3 4 
do 
    for n in $nices 
    do 
    nice $n ruby ,count_loops.rb > ,n${n}-$i & 
    done 
done 
ps -l 
uptime 
wait 
uptime 
ps -l 
c=`cat ,n-0-[1234] | total` 
last=$c 
for n in $nices 
do 
    echo 
    c2=`cat ,n${n}-[1234] | total` 
    echo total of `cat ,n${n}-[1234]` is $c2 
    echo -n "nice $n count $2, percentage: " 
    echo "3 k $c2 100 * $c/p" | dc 
    echo -n "     percent of last: " 
    echo "3 k $c2 100 * $last/p" | dc 
    last=$c2 
done 
uptime 
echo total count: `cat ,n-*-[1234] | total` 

, archivo count_loops.rb

#!/usr/bin/env ruby 
limit = Time.new + 70 
i=0 
while Time.new < limit 
i += 1 
j = 0 
while (j += 1) < 10000 
    t = j 
end 
end 
puts i 

resultados de sh ,cl - salida de diagnóstico inicial:

19:16:25 up 20:55, 2 users, load average: 3.58, 3.59, 2.88 
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY   TIME CMD 
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash 
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh 
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java 
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64 
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh 
0 R 1000 19616 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19617 19613 0 82 2 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19618 19613 0 84 4 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19619 19613 0 86 6 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19620 19613 0 88 8 - 6795 -  pts/3 00:00:00 ruby 
0 R 1000 19621 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19622 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19623 19613 0 94 14 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19624 19613 0 96 16 - 6078 -  pts/3 00:00:00 ruby 
0 R 1000 19625 19613 0 98 18 - 6012 -  pts/3 00:00:00 ruby 
0 R 1000 19626 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19627 19613 0 82 2 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19628 19613 0 84 4 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19629 19613 0 86 6 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19630 19613 0 88 8 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19631 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19632 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19633 19613 0 94 14 - 6144 -  pts/3 00:00:00 ruby 
0 R 1000 19634 19613 0 96 16 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19635 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19636 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19637 19613 0 82 2 - 7449 -  pts/3 00:00:00 ruby 
0 R 1000 19638 19613 0 84 4 - 7344 -  pts/3 00:00:00 ruby 
0 R 1000 19639 19613 0 86 6 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19640 19613 0 88 8 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19641 19613 0 90 10 - 6210 -  pts/3 00:00:00 ruby 
0 R 1000 19642 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19643 19613 0 94 14 - 5976 -  pts/3 00:00:00 ruby 
0 R 1000 19644 19613 0 96 16 - 6111 -  pts/3 00:00:00 ruby 
0 R 1000 19645 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19646 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19647 19613 0 82 2 - 7516 -  pts/3 00:00:00 ruby 
0 R 1000 19648 19613 0 84 4 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19649 19613 0 86 6 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19650 19613 0 88 8 - 6177 -  pts/3 00:00:00 ruby 
0 R 1000 19651 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19652 19613 0 92 12 - 6078 -  pts/3 00:00:00 ruby 
0 R 1000 19653 19613 0 94 14 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19654 19613 0 96 16 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19655 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19656 19613 0 80 0 - 3908 -  pts/3 00:00:00 ps 
19:16:26 up 20:55, 2 users, load average: 3.58, 3.59, 2.88 
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59 
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY   TIME CMD 
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash 
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh 
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java 
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64 
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh 
0 R 1000 19794 19613 0 80 0 - 3908 -  pts/3 00:00:00 ps 

resultados de sh ,cl - estadísticas: (porcentaje de la última es el porcentaje de este total se compara con el recuento para el último grupo de procesos)

total of 99951 101725 100681 104046 is 406403 
nice -0 count , percentage: 100.000 
        percent of last: 100.000 

total of 64554 62971 64006 63462 is 254993 
nice -2 count , percentage: 62.743 
        percent of last: 62.743 

total of 42997 43041 43197 42717 is 171952 
nice -4 count , percentage: 42.310 
        percent of last: 67.434 

total of 26882 28250 27151 27244 is 109527 
nice -6 count , percentage: 26.950 
        percent of last: 63.696 

total of 17228 17189 17427 17769 is 69613 
nice -8 count , percentage: 17.129 
        percent of last: 63.557 

total of 10815 10792 11021 11307 is 43935 
nice -10 count , percentage: 10.810 
        percent of last: 63.113 

total of 7023 6923 7885 7323 is 29154 
nice -12 count , percentage: 7.173 
        percent of last: 66.357 

total of 5005 4881 4938 5159 is 19983 
nice -14 count , percentage: 4.917 
        percent of last: 68.542 

total of 3517 5537 3555 4092 is 16701 
nice -16 count , percentage: 4.109 
        percent of last: 83.576 

total of 4372 4307 5552 4527 is 18758 
nice -18 count , percentage: 4.615 
        percent of last: 112.316 
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59 
total count: 1141019 

(puristas señalar estoy mezclando rubí, concha y DC - lo harán tengo que perdonarme por los viejos hábitos del siglo pasado;))

3

El comportamiento que está viendo es casi seguro debido a la función de autogrupo que se agregó en Linux 2.6.38 (en 2010). Presumiblemente cuando describió la ejecución de los dos comandos, se ejecutaron en ventanas de terminal diferentes. Si los había ejecutado en la misma ventana del terminal , entonces debería haber visto que el buen valor tiene un efecto. El resto de esta respuesta elabora la historia.

El núcleo proporciona una característica conocida como autoagrupar para mejorar el rendimiento escritorio interactivo en la cara de multiproceso, las cargas de trabajo intensivas de la CPU como la construcción del núcleo de Linux con un gran número de procesos de construcción paralelas (es decir, la bandera make(1) -j).

Se crea un nuevo autogrupo cuando se crea una nueva sesión a través de setsid(2); esto sucede, por ejemplo, cuando se inicia una nueva ventana de terminal. Un nuevo proceso creado por fork(2) hereda la membresía de autogrupo del padre . Por lo tanto, todos los procesos en una sesión son miembros del mismo autogrupo.

Cuando se habilita la agrupación automática, todos los miembros de un autogrupo se colocan en el mismo "grupo de tareas" del planificador de kernels. El programador del kernel de Linux emplea un algoritmo que iguala la distribución de los ciclos de CPU en los grupos de tareas. Los beneficios de esto para el rendimiento de escritorio interactivo se pueden describir a través del siguiente ejemplo.

Supongamos que hay dos autogroups que compiten por la misma CPU (es decir, suponer o bien un sistema de CPU solo o el uso de taskset(1) para confinar todos los procesos a la misma CPU en un sistema SMP). El primer grupo contiene diez procesos vinculados a la CPU de una creación de kernel comenzada con make -j10. El otro contiene un solo proceso de CPU : un reproductor de video. El efecto de la autoagrupación es que los dos grupos recibirán la mitad de los ciclos de la CPU. Es decir, , el reproductor de video recibirá el 50% de los ciclos de la CPU, en lugar de solo el 9% de los ciclos, lo que probablemente ocasione una reproducción de video degradado .La situación en un sistema SMP es más compleja, pero el efecto general es el mismo: el planificador distribuye ciclos de CPU entre grupos de tareas, de forma que un autogrupo que contiene un gran número de procesos vinculados a CPU no termina acaparando ciclos de CPU a expensas de los otros trabajos en el sistema.

El valor agradable y programación de grupos

Al programar los procesos en tiempo no real (por ejemplo, aquellos que está previsto bajo la política predeterminada SCHED_OTHER), el programador emplea una técnica conocida como "programación de grupos", bajo qué hilos están programados en "grupos de tareas". Los grupos de tareas se forman en las diversas circunstancias, con el caso relevante aquí se autoagrupa.

Si se habilita el autoagrupar, entonces todos los hilos que son (implícitamente) colocados en un Autogroup (es decir, la misma sesión, como creado por setsid(2)) forman un grupo de tareas. Cada nuevo autogrupo es , por lo tanto, un grupo de tareas por separado.

Bajo programación de grupos, buen valor de un hilo tiene un efecto para decisiones de planificación sólo en relación con otros hilos en el grupo de tarea misma . Esto tiene algunas consecuencias sorprendentes en términos de la semántica tradicional del buen valor en los sistemas UNIX. En particular, si está habilitada la autoagrupación (que es la predeterminada en varias distribuciones de Linux), entonces empleando nice(1) en un proceso tiene un efecto solo para la programación relativa a otros procesos ejecutados en la misma sesión (típicamente: la misma ventana de terminal) .

el contrario, para dos procesos que son (por ejemplo) los únicos procesos vinculados a la CPU en diferentes sesiones (por ejemplo, diferentes terminales ventanas, cada uno de cuyos puestos de trabajo están vinculados a diferentes autogroups), modificando el valor agradable de el proceso en una de las sesiones tiene sin efecto en términos de las decisiones del planificador en relación con el proceso en la otra sesión. Presumiblemente, este es el escenario que vio, aunque no menciona explícitamente el uso de dos ventanas de terminal.

Si desea evitar que autoagrupar interferir con el comportamiento tradicional nice como se describe aquí, se puede desactivar la función de

echo 0 > /proc/sys/kernel/sched_autogroup_enabled 

Ten en cuenta que esto también tendrá el efecto de desactivación de los beneficios para la interactividad de escritorio que la función de autogrupo estaba destinada a proporcionar (ver arriba).

El buen valor Autogroup

membresía Autogroup de un proceso puede ser visto a través de el archivo /proc/[pid]/autogroup:

$ cat /proc/1/autogroup 
/autogroup-1 nice 0 

Este archivo también se puede utilizar para modificar el ancho de banda de la CPU asignada a un Autogroup . Esto se hace escribiendo un número en el rango "bueno" en el archivo para establecer el buen valor del autogrupo. El rango de permitido es de +19 (baja prioridad) a -20 (alta prioridad).entorno agradable

El Autogroup tiene el mismo significado que el valor agradable proceso , pero se aplica a la distribución de ciclos de CPU a la Autogroup como un todo, basado en los valores agradables relativos de otros autogroups. Para un proceso dentro de un autogrupo, la CPU ciclos que recibe será un producto del buen valor del autogrupo (comparado con a otros autogrupos) y el buen valor del proceso (en comparación con otros procesos en el mismo autogrupo).

Cuestiones relacionadas