2012-01-16 15 views
5

Estaba leyendo sobre cómo funciona Linux en mi OS-libro cuando me encontré con este ..¿Llamada al sistema sin cambio de contexto?

[...] el núcleo se crea como un único binario, monolítico. La razón principal es mejorar el rendimiento. Debido a que todos los códigos del kernel y las estructuras de datos se guardan en un único espacio de direcciones, no son necesarios los cambios de contexto cuando un proceso llama a una función del sistema operativo o cuando se entrega un hardware de interrupción.

Eso me sonaba bastante sorprendente, seguramente debe almacenar el contexto del proceso antes de pasar al modo kernel para manejar una interrupción ... Pero está bien, lo compraré por ahora. Unas pocas páginas, mientras describía el contexto de programación de un proceso, decía:

Ambas llamadas al sistema e interrupciones que ocurren mientras el proceso se está ejecutando usarán esta pila.

"esta pila" es el lugar donde el kernel almacena los registros del proceso y tal.

¿No es esto una contradicción directa con la primera cita? ¿Lo estoy malinterpretando de alguna manera?

Respuesta

3

Creo que la primera cita se refiere a las diferencias entre un kernel monolítico y un microkernel.

Linux siendo monolítico, todos sus componentes kernel (controladores de dispositivo, planificador, administrador de VM) se ejecutan en ring 0. Por lo tanto, no es necesario un cambio de contexto cuando se realizan llamadas al sistema y se manejan interrupciones.

microkernels el contrario, cuando los componentes como los controladores de dispositivos y proveedores de IPC se ejecutan en user space, fuera del anillo de 0. Por lo tanto, esta arquitectura requiere un contexto adicional conmuta al realizar llamadas de sistema (debido a que el módulo de interpretación pueden residir en el espacio de usuario) y las interrupciones de manipulación (para retransmitir las interrupciones a los controladores del dispositivo).

+0

Gracias. Ha pasado mucho tiempo desde que estudié esto, pero tenía la impresión de que las interrupciones de hardware realmente interrumpían la ejecución y saltaban de inmediato al procedimiento de manejo en lugar de sondear para interrupciones más adelante. Pensé que si el proceso se ejecutaba en modo kernel, aún tendría que almacenar su contexto antes de ese salto, pero quizás ese fue mi error. Supongo que ahora eso no sería diferente de cualquier otra llamada a método si el método llamado maneja correctamente los registros usados ​​... ¿lo entendí bien? – user1130005

+0

Según tengo entendido, el proceso se está ejecutando en modo de usuario y, de hecho, hay un cambio de contexto al modo kernel antes de que se maneje la interrupción. Sin embargo, * handling * la interrupción no requiere un cambio de contexto adicional en núcleos monolíticos, pero sí en microkernels (ya que los controladores de dispositivo residen en el espacio de usuario). –

2

"Context switch" podría significar una de dos cosas, ambas relevantes: (1) cambiar de usuario a modo kernel para procesar la llamada al sistema, o un cambio involuntario al kernel para procesar una interrupción contra la pila de interrupción , o (2) cambiar para ejecutar otro proceso de usuario en el espacio de usuario, con un salto al espacio del núcleo entre los dos.

Cualquier movimiento del espacio de usuario al espacio del kernel implica guardar suficiente espacio de usuario para volver de forma confiable. Si el código de espacio del kernel decide que, mientras ya no está ejecutando el código de usuario para ese proceso, es hora de dejar que se ejecute otro proceso de usuario, entra.

Por lo menos, está hablando 2-3 pilas o lugares para almacenar un "contexto": las interrupciones de hardware necesitan una pila de nivel de kernel para decir a qué volver; las llamadas de subrutina/método de usuario usan una pila estándar para hacerlo. Etc.

Los núcleos Unix originales - y el modelo no es tan diferente ahora para esta parte - ejecutó las llamadas del sistema como un pedido de desayuno de cocción breve pedidos de desayuno: mueva esto sobre la estufa para dejar espacio para la orden de tocino que acaba de llegar, inicia el tocino, vuelve al primer orden. Todo en el contexto de cambio de kernel. No era una gran aplicación de supervisión, lo que probablemente enloqueció a los profesionales del software IBM y DEC.

0

Al realizar una llamada al sistema en Linux, se realiza un cambio de contexto desde el espacio de usuario al espacio del kernel (ring3 a ring0). Cada proceso tiene una pila de modo kernel asociada, que es utilizada por la llamada al sistema.Antes de que se ejecute la llamada al sistema, los registros de CPU del proceso se almacenan en su pila de modo de usuario, esta pila es diferente de la pila de modo kernel, y es la que utiliza el proceso para las ejecuciones de espacio de usuario.

Cuando un proceso está en modo kernel (o modo de usuario), las funciones de llamada del mismo modo no requerirán un cambio de contexto. Esto es lo que se refiere en la primera cita.

La segunda cita se refiere a la pila del modo kernel, y no a la pila del modo de usuario.

Habiendo dicho esto, debo mencionar optimizaciones Linux, donde no se necesita una transición al espacio del núcleo para la ejecución de una llamada al sistema, es decir, todo el procesamiento relacionado con la llamada al sistema se realiza en el espacio de usuario en sí (por lo tanto no context switch). vsyscall, y VDSO son tales técnicas. La idea detrás de ellos es bastante simple. Es para enviar al espacio de usuario, los datos que se requieren para la ejecución de la llamada al sistema correspondiente. Se puede encontrar más información en this LWN article.

Además de esto, ha habido algunos proyectos de investigación en los que toda la ejecución ocurre en el mismo anillo. Los programas de espacio de usuario y el código del sistema operativo residen en el same ring. La idea es deshacerse de la sobrecarga de los interruptores de anillo. Microsoft's [singularity][2] OS es uno de esos proyectos.

Cuestiones relacionadas