Sistemas operativos modernos

que dicho mecanismo sólo funciona cuando el controlador de reloj y el procedimiento a invo­ car están en el mismo espacio de direcciones. El último elemento de nuestra lista es la creación de perfiles. Algunos sistemas operativos proporcionan un mecanismo mediante el cual un programa de usuario puede pedir al sistema que construya un histograma de su contador de programa, para saber dónde pasa su tiempo. Si es posible crear perfiles, el controlador verifica en cada tic si se está manteniendo un perfil del proceso actual y, si así es, calcula el número de urna (un intervalo de direcciones) correspon­ diente al contador de programa actual. Luego incrementa en uno la urna. Este mecanismo tam­ bién puede servir para crear un perfil del sistema mismo. 5.5.3 Temporizadores de software Casi todas las computadoras fienen un segundo reloj programable que puede ajustarse de modo que cause interrupciones con la frecuencia que las necesite un programa. Este temporizador es adicional al temporizador principal del sistema, cuyas funciones acabamos de describir. Mien­ tras la frecuencia de las interrupciones sea baja, no habrá problema si este segundo temporiza­ dor se utiliza con fines específicos para una aplicación dada. El problema surge cuando la frecuencia del temporizador específico para la aplicación es muy alta. A confinuación describi­ remos con brevedad un esquema de temporizador basado en software que funciona bien en mu­ chas circunstancias, incluso a frecuencias altas. La idea se debe a Aron y Druschel (1999). Si desea más detalles, puede consultar su artículo. En genera!, hay dos formas de administrar la E/S: interrupciones y sondeos. Las interrup­ ciones fienen latencia baja, es decir, se presentan inmediatamente después del suceso mismo, con poco o ningún retraso. Por otro lado, con las CPUs modernas las interrupciones represen­ tan un gasto extra considerable debido a la necesidad de conmutar el contexto y a su influen­ cia sobre la canalización, el TLB y el caché. La alternativa al uso de interrupciones es hacer que la aplicación misma pregunte si ya se presentó el suceso esperado. Esto evita las interrupciones pero podría haber una latencia apre­ ciable porque un suceso podría presentarse inmediatamente después del sondeo, en cuyo caso la aplicación esperará casi un intervalo de sondeo entero. En promedio, la latencia es la mitad del intervalo del sondeo. Para algunas aplicaciones, ni el gasto adicional de las interrupciones ni la latencia de los sondeos son aceptables. Por ejemplo, consideremos una red de alto rendimiento como Gigabit Ethernet. Esta red puede aceptar o entregar un paquete de tamaño completo cada 12 |xs. Para funcionar con un desempeño óptimo en operaciones de salida, deberá enviarse un paquete ca­ da 12 i^s. Una forma de alcanzar estas velocidades es hacer que la transmisión de un paquete comple­ to cause una interrupción, o establecer el segundo temporizador de modo que interrumpa cada 12 |is. El problema es que esta interrupción tarda 4.45 p.s en una Pentium II de 300 MHz (Aron y Druschel, 1999). Este gasto adicional no es mucho menor que el que tenían las computadoras en los años setenta. En la mayoría de las minicomputadoras, por ejemplo, una interrupción re­ quería cuatro ciclos de bus en total para meter a la pila el contador de programa y la PSW, y para cargar el nuevo contador de programa y la nueva PSW. En la actualidad, el manejo de canaliza­ ciones, la MMU, el TLB y el caché, producen un gasto adicional mucho mayor. De seguro es