Sobre sched: automatizado por grupos de tareas de TTY

Question

Soy nuevo en el desarrollo del kernel y yo estoy tratando de entender sobre el nuevo parche del kernel sched:. automatizado por TTY grupos de tareas

Puede alguien explicar brevemente qué es exactamente lo que está haciendo?

Answer 1

Mi impresión del parche (la luz en el detalle de que la mayoría de los artículos al respecto son) era que se puede equilibrar de manera más uniforme las proporciones de la CPU de forma automática.

El CFS Linux completamente Fair Scheduler ha tenido un comportamiento de equilibrio de grupo por un tiempo. Lo que esto significa es que si el usuario A comienza a 500 tareas y el usuario B inicia sólo una, la equidad debe equilibrar entre el usuarios , no las tareas.

A tal efecto, todos los puestos de trabajo de usuario A debe estar en un grupo y todos los puestos de trabajo del usuario B en otro, y la CPU será compartida en partes iguales entre ellos - el usuario A no puede ser más capacidad sólo porque son antisocialmente correr más tareas.

Sin embargo, la equidad se basa o bien en el identificador de usuario (dinámica) o grupos de control (una configuración de métodos relativamente doloroso, estática).

Lo que este parche parece que hacer es asignar automáticamente los trabajos a un grupo en base a su TTY. De ese modo, la separación en grupo se convierte en una función automática (sin la creación de grupos de control), y uno que ocurre en un grano más fino que el ID de usuario (desde ordenadores de sobremesa típicos única Tienes un usuario haciendo la mayor parte del puestos de trabajo, al menos los que no auto-administración).

Así que, cuando Linus se sienta a compilar el siguiente kernel para nosotros, el proceso de construcción masiva en paralelo tiene todas sus funciones ponen en un grupo y Linus pueden disparar hasta VLC para ver el último episodio de The Big bang Theory (no tengo ni idea de si él ve este espectáculo, ni si tiene varias piezas de software en su caja, para todo lo que sé, se puede ejecutar Windows Media Player en Windows 7) en un grupo totalmente independiente.

La CPU se compartirá relativamente igual entre los dos grupos , y Linus no tiene que ver Sheldon mueva a sacudidas por la pantalla.

Se va a ralentizar la construcción del kernel, por supuesto, pero no es como si eso es una tarea importante que está realizando para nosotros. Podemos esperar un poco si esto significa que sus niveles de sanidad se mantienen: -)

Por lo que he leído (y visto), este en gran medida mejora la capacidad de respuesta de las aplicaciones de escritorio. Que no le da la capacidad más general pero mejora mucho las cosas en ciertos escenarios.

Por supuesto, si su perfil de uso es una tarea por TTY (o todas las tareas en una sola TTY), es probable que no ayuda mucho. Pero, si mejora algunos escenarios y no se degrada demasiado muchos otros, que va a ser un ganador. Y, aunque hace otras degradan, que es un comportamiento configurable, por lo que probablemente todavía colarse en el kernel.

---

Curiosamente, ahora que este candidato parche ha ido "medios de comunicación", hay personas que salen de la madera que indica que puede hacer la mismo con modificaciones en su .bashrc y algunos otros ajustes menores. Esto básicamente envuelve una herramienta "automatizado" alrededor de los grupos de control que he mencionado anteriormente.

Linus ya ha rechazado esta solución muy fácil de la tierra ya que quiere que sea independiente del shell y esto no es algo que los usuarios deberían tener que hacer:

  

Debido a que es algo que queremos que lo haga por todos los usuarios, y para todas las conchas, y asegúrese de que se realiza de forma automática. Incluso para los usuarios que tienen distribuciones de edad, etc, y que sea fácil de hacer en un solo lugar. Y entonces lo haces por todos los demás heurística que podemos ver fácilmente en el núcleo. Y entonces lo haces mágicamente sin que los usuarios ni siquiera tener que notificación .

     

De repente no parece que ninguna maravilla más para jugar con bashrc, ¿verdad?

     

Ese es el punto. Podemos empujar a cabo el cambio de kernel, y todo va a "trabajar solo". Podemos hacer que la característica que ya tenemos en el núcleo de hecho ser utilidad .

     

configuración de nivel de usuario para obtener algo que debe just trabajo es molesto. Podemos hacerlo mejor.

     

Dicho de otra manera: si encontramos una mejor manera de hacer algo, debemos no decir "bueno, si los usuarios quieren, pueden hacer esto ". Si realmente es una mejor manera de hacer algo, debemos simplemente lo hacemos. Que requiere la configuración de usuario es no una característica.

     

Ahora, no estoy diciendo que no debemos permitir a los usuarios a cgroups uso. Por supuesto que pueden hacer las cosas de forma manual también. Pero no hay que exigir a los usuarios a hacer cosas tontas que podemos hacer más fácil a nosotros mismos.

     

Si la elección es entre todo el mundo diciendo "usted debe hacer esto", y "que deberíamos hacer esto para usted", me quedo con el segundo cada vez. Sabemos que se debe hacer. ¿Por qué le decimos a alguien que lo haga por nosotros?

Estoy de acuerdo con ese sentimiento -. Si se acaba permite avisar al usuario de que tenían que hacer algo especial para un rendimiento adicional, usted podría conseguir que el uso "nice make -j64" en lugar de "make -j64"