Kernel Linux y renice/ionice

[Ricardo Albarracin B.]

El Tue, 1 Feb 2011 17:16:19 -0300
Daniel Serpell <dserpell en gmail.com> escribió:
> ¡Hola!

Estimado amigo... un gusto como siempre..

> Lo que más te conviene aquí es cambiar la clase de schedulling del
> programa, pasar de la clase estándar a la clase round-robin. Esto
> garantiza que tu aplicación va a recibir CPU cada cierto tiempo por
> lo menos.

Perfecto... es la idea.
 
> Para hacerlo, basta con utilizar la llamada sched_setscheduler(), ve
> en su página de manual. En nuestro caso, agregamos esto:
> 
>  void set_priority()
>  {
>      struct sched_param sp;
>      sp.sched_priority = 10;
>      sched_setscheduler(0, SCHED_RR, &sp);
>  }

bien... 

> Todas las tareas en round-robin tienen más prioridad que las tareas
> estándares, esto significa que si usas el 100% de CPU, nada más se
> ejecutará en tu computador. Esto no es un problema si la aplicación
> sólo recibe datos, ya que debería realizar la recepción y luego volver
> a esperar más datos.

Perfecto, esto me resolvería el overflow de los buffers.

> El problema ahora es que no quieres que la aplicación tenga permisos
> de super-usuario.

Es la idea final... pero para probar no me complica que lo haga
momentáneamente.

>                    Si usas Linux mayor a 2.6.12, la solución es
> cambiar el límite de prioridad permitida de los procesos por medio de
> la capacidad "RLIMIT_RTPRIO" usando setrlimit. Esto se hace con el
> siguiente pseudocódigo:
> 
>  // Programa ejecutado con UID=0, cambia los límites
>  setrlimit(...);
>  if(!fork())
>  {
>   // Cambia a usuario 1000 (por ejemplo)
>   setuid(1000);
>   // Ejecuta el programa
>   execve(....);
>  }
>  // Termina.
>  exit(0);

Ok... se ve simple el cambio.

> Obviamente, con manejo de errores, etc. Lamentablemente el programa
> "padre" debe todavía ser root, esto es difícil de evitar, ya que de
> alguna manera se tiene que dar el permiso.

cierto... 

> Nota que en versiones de Linux mayores a 2.6.25 puedes también fijar
> el límite "RLIMIT_RTTIME", el cual limita el total de tiempo que un
> proceso de prioridad RT puede utilizar de una sola vez. Esto sirve
> para impedir que un proceso RT use el 100% de CPU y haga que el resto
> del sistema no responda. Ve en el manual de "setrlimit".

Ok...

> Por último, si insistes en que el proceso inicial (que fija los
> límites) no sea ejecutado como root, puedes utilizar el sistema de
> capacidades de Linux, ve capabilities(7), con énfasis en la sección
> llamada "File Capabilities". La gracia es que, si usas un sistema
> de archivos que lo soporte, puedes asignar a un ejecutable la
> capacidad "CAP_SYS_NICE", usando "setcap cap_sys_nice+p programa".
> Lee bien, eso si, lo que esto permite al proceso.

ok... quedé con bastante pega por delante :-)

> Lamentablemente, en UBIFS que usamos aquí no hay soporte para
> capabilities.

Ok... pero en definitiva no es tan grave por el momento, el primero
objetivo a lograr es evitar el problema de perdida de datos en máquinas
pequeñas.... luego veremos los temas de seguridad y escalamiento de
privilegios.
 
>     Daniel.

Gracias estimado amigo por tus comentarios, han sido de mucha utilidad,
siempre un gusto compartir experiencias.

-- 
Atentamente.
+-----------------------+-------------------------+
| Ricardo Albarracin B. | email: ralbab en gmail.com |
+-----------------------+-------------------------+