La idea es facil: cuando un procesador no tiene nada que hacer se echa a dormir y las interrupciones le despiertan para que trabaje. Cuantas menos haya, menos trabaja el procesador y más energía ahorra. Históricamente el procesador recibia un numero determinado de interrupciones por segundo (generalmente 1000) para repartir mejor el tiempo de proceso. Esto es necesario para que un proceso no se quede con todo el tiempo de cpu cuando hay más procesos queriendo ejecutar, pero es totalmente innecesario cuando no hay nada que hacer, que suele ser el 99% del tiempo que se navega por internet o y el 95% cuando se hacen trabajo ligeros como ofimática y escuchar música. En los nucleos nuevos, >2.6.21 se ha introducido un mecanismo nuevo, de kernel "tickless" o "noHz", es decir, sin interrupciones gratuitas. El invento está muy bien como concepto pero es un pelín complejo, ya que (mas o menos) el kernel ha de prever cuándo va a necesitar despertarse, programarse un despertador y echarse a dormir.
Por desgracia, en las versiones actuales hay algo que falla y surjen dos problemas, ambos visibles en el powertop:
1. Interrupciones innecesarias. Ya sea por programas hiperactivos o drivers con problemas. Algunos programas programan temporizadores para despertarse 100 veces por segundo para ver si ha pasado algo. Algunos drivers hacen interrupciones innecesarias y el propio nucleo a veces se sobra con las mismas. Por ejemplo, la tarjeta wifi interrumpe cada vez que "escucha" un punto de acceso. Dado que cada punto de acceso se anuncia cada 100ms, tenemos 10 interrupciones por segundo por cada AP que haya cerca. Y el prorpio kernel genera eventos, porlo que he leído prescindibliles, como "
2. Problema con C-States. Este es más grave, ya que tras un tiempo encendido pasa algo que impide que el procesador "se duerma", generando desde 5.000 hasta 200.000 interrupciones por segundo, según el caso. En mi Core Duo T2400: Wakeups-from-idle per second : 24434,0 interval: 10,0s. El problema es escurridizo pero están trabajando en el. A veces se soluciona descargando el módulo yenta_socket, a veces quitando los parches de hibernación (antes suspend2, ahora tuxonice), a veces volviendo a un kernel 2.6.22 y otras veces de ninguna manera. Hay algún hilo sobre ello en las listas de energía, en el bugzilla (2) de Novell (Suse), en el de Ubuntu, y en unos pocos más en las lists del kernel. El problema aún no tiene solución real, aunque en mi caso se puede paliar recargando el yenta_socket:
pioneer ~ # rmmod yenta_socketEl análisis más encaminado por el momento parece ser este, aunque espero que pronto se resuelva, el ventilador la batería del portátil lo agradecerán (4º C y 1h respectivamente).
pioneer ~ # modprobe yenta_socket
Bueno, yo a seguir estudiando sistemas operativos, ¡que viene al cuento!
No comments:
Post a Comment