Mailinglist Archive: opensuse-es (1469 mails)

[Rafa Grimán <rgriman@xxxxxxx>]

Hola :)

El Jueves, 5 de Octubre de 2006 13:50, Carlos E. R. escribió:

[...]

> > > Lo que no se es porqué los de mythtv no usan una partición raw para
> > > el buffer circular de recepción/visionado.
> >
> > El usar raw implica "ignorar" las cachés y los buffers y acceder
> > directamente al dispositivo. Esto para vídeo no es tan bueno porque lo
> > que te interesa es que el streaming se haga desde memoria (más rápido y
> > menos latencia) que desde disco. Además, si dos procesos están
> > accediendo a dos sectores diferentes de disco ... el rendimiento (en el
> > caso de raw) caerá vertiginosamente porque el cabezal tiene que bascular
> > mucho :(
>
> Pues curiosamente los de xine creo que usan raw precisamente para evitar
> el uso de la cache, porque al ser un fichero enorme que se lee una única
> vez no tiene sentido guardarlo en memoria que es más util para otros


Siempre y cuando hablemos de un proceso que accede a disco, ¿qué ocurre si son 
muchos usuarios que acceden a vídeo en tiempo real? Pues que no es sostenible 
esto. Necesitas cachear todo lo que puedas a memoria porque los cabezales 
están como locos saltando de un vídeo a otro para satisfacer las peticiones 
del resto de usuarios y procesos.


> ficheros del proceso normal del sistema, que se enlentece globalmente.
> Creo que en esos casos es más eficaz una caché dedicada al proceso en
> cuestión, o un bufer de lectura grande; es decir, limitar el tamaño de
> caché dedicado a ese proceso.


Eso también es interesante, poder gestionar la caché o los buffers en función 
de tus necesidades. En el kernel, se pueden retocar mediante proc, pero nunca 
he tenido que hacerlo.


> En mis tiempos que me ganaba los garbanzos programando en dos lo noté: la
> copia de ficheros era muy rápida si a la función de lectura de un fichero
> le asignaba un bufer de 64 KiB (lo normal creo que era menos de un k). En
> el caso de tener un cache de sistema, el fichero es primero leido en un
> golpe grande (o varios) al caché del sistema, y de ahí se copia al bufer
> de lectura, y de ahí una tercera vez a la memoria del programa (las dos
> ultimas se podrían juntar, en teoría). Sin caché de sistema te ahorras
> un movimiento de memoria.


Sí, pero si te hacen una segunda petición, el dato está cacheado y se sirve 
más deprisa :) Un ejemplo, en un cliente nuestro (una televisión) tienen una 
máquina con 32 GB de RAM ... imagínate cómo cachea el SLES ;) Claro, la 
segunda vez que se pide el fichero ... la latencia tiende a 0 por lo que el 
cliente lo recibe en seguida. Eso sí, si abres dos vídeos ... los tienes los 
dos en memoria y al hacer un free ves que libres hay 5 MB xD


>    O dicho de otra forma, el programador del proceso conoce el tipo de
>    entrada/salida que va a necesitar y se puede optimizar. El programador
>    de la caché no: puede orientarla por sectores contiguos de disco, por
>    ficheros completos, por peticiones de procesos, mezclas, algoritmos
>    inteligentes... y todo porque no sabe realmente que es lo que le van a
>    pedir.


Eso es otra historia: hoy en día el desarrollador de aplicaciones se basa ne 
lo que hacen los desarrolladores del kernel, pero no piden que se implementen 
determinadas cosas. Por ejemplo, en Linux, el tamaño de bloque máximo son 16 
KB (si no recuerdo mal), ¿qué ocurre si mi aplicación funciona mejor leyendo 
bloques más grandes?


> > > Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a
> > > dedicarle una partición gigante a él solito, y sólo para probarlo.
> >
> > Yo estuve un tiempo probando JFS y no me gustó una cosa: es poco fiable
> > si se compila como módulo :( Si quieres que sea fiable y no perder datos
> > ... inclúyelo en el kernel !!
>
> Lo recuerdo, estuvimos hablando de eso aquí :-)
>
> Y puede dar guerra si a SuSE se le ocurre no ponerlo en el disco de
> rescate.


Cierto.

   Rafa

-- 
"Even paranoids have enemies."

Rafa Grimán
Systems Engineer

Silicon Graphics Spain
Santa Engracia, 120 - Planta Baja
28003 Madrid
Spain

Tel: +34 91 3984200
Tel: +34 91 3984201
Móvil: +34 628 117 940

http://www.sgi.com

OpenWengo: rgriman
Skype:     rgriman