1. OpenSolaris 2008.05
OpenSolaris Indiana 2008.05 en una máquina virtual creada
con VirtualBox 1.6 bajo el Sistema Operativo Kubuntu 8.04
Amd64

2. OpenSolaris: Procesos
➢ Los ficheros mantienen información sobre los distintos procesos
que se están ejecutando en la máquina, OpenSolaris utiliza un
pseudo sistema de ficheros llamado Procfs, en el cual, el kernel
mantiene información sobre los procesos que está corriendo.
➢ El sistema de archivos procfs está organizado en directorios,
uno por cada proceso en que se ejecuta en la máquina, los
directorios se llaman con el PID del proceso del cual mantienen
la información. Ejemplo:

3. OpenSolaris: Procesos
(root@Carlos)# cd /proc
(root@Carlos)# ls
0 14470 18279 19575 22216 2496 28190 3782 4622 605
1 1464 18340 19604 22610 25190 28252 398 4636 606
10192 1465 18709 19634 22645 25229 285 421 472 6347
10622 14896 18779 2 23054 25479 28610 4210 476 664
...
(root@Carlos)#
➢ Cada uno de estos ficheros que representa a un proceso contiene una serie
de ficheros y directorios, de los cuales podemos obtener información sobre el
proceso y todos sus LWP.

4. OpenSolaris: Procesos
Ejemplo:
(root@carlos)# cd 29039
(root@carlos)# ls ­l
total 5933
­rw­­­­­­­ 1 noxos noxos 2998272 May 16 12:13 as
­r­­­­­­­­ 1 noxos noxos 152 May 16 12:13 auxv
­r­­­­­­­­ 1 noxos noxos 36 May 16 12:13 cred
­­w­­­­­­­ 1 noxos noxos 0 May 16 12:13 ctl
lr­x­­­­­­ 1 noxos noxos 0 May 16 12:13 cwd ­>
dr­x­­­­­­ 2 noxos noxos 8208 May 16 12:13 fd
...
(root@carlos)#

5. OpenSolaris: Procesos
Ficheros:
➢ /proc/< pid >/as
➢ /proc/< pid >/auxv
➢ /proc/< pid >/cred
➢ /proc/< pid >/ctl
➢ /proc/< pid >/cwd
➢ /proc/< pid >/fd/
➢ /proc/< pid >/psinfo
➢ /proc/< pid >/map
➢ /proc/< pid >/object/
➢ /proc/< pid >/pagedata
➢ /proc/< pid >/sigact
➢ /proc/< pid >/status

6. OpenSolaris: Fallos
 MDB (Modular Debugger) es una herramienta que nos puede ayudar a
conocer las causas que provocaron un fallo, MDB trabaja con los ficheros
core, que son una imagen de memoria del proceso que ha sufrido el fallo,
esto nos permitía averiguar cuales fueron la causa de dicho fallo.
 MDB no solo puede trabajar con los volcados de memoria de los procesos,
sino que también lo puede hacer con las imágenes de memoria del kernel
mientras este está ejecutándose, esto nos permite poder acceder a toda la
información, si sabemos como leerla, con la que trabaja el kernel, lista de
procesos, páginas de memoria, ficheros abiertos, listas de espera, conexiones
de red, bloqueos, etc.

7. OpenSolaris: Fallos
 Para que MDB acceda a la imagen del memoria del Kernel
debemos saber como fichero objeto debemos utilizar
/dev/ksyms el cual contiene la tabla de símbolos y como
fichero core utilizaremos /dev/kmem, por lo tanto podemos
ejecutar la siguiente línea.
(root@carlos)# mdb /dev/ksyms /dev/kmem
Loading modules: [ unix krtld genunix ip usba ipc random nfs
ptm ]
>

8. OpenSolaris: Fallos
 Lo que debemos conocer de MDB para comenzar a trabajar con él es que se
basa en los siguientes tres elementos:
­dmods son los módulos que se cargan en el debugger, dependiendo de los
módulos que se hayan cargado podremos realizar más o menos acciones.
­dcmds son los comandos que podemos utilizar en el debugger.
­walkers son sencillos programas que nos permiten iterar sobre una serie de
datos.

9. OpenSolaris: Paginación
 Todos los procesos, disponen de su propio espacio de direcciones de
memoria, los espacios de direcciones están formados por segmentos de
memoria, un espacio de direcciones tiene al menos 4 segmentos de
memoria, el de datos, el de texto, el de heap y el de stack. Cada
segmento de memoria está formado por un número determinado de páginas
de memoria.
 Las páginas tienen un tamaño fijo, son de 8K, con el comando pagesize
podemos ver qué tamaños de página podemos utilizar en nuestro sistema y
cual es el tamaño por defecto (8k). Utilizando el ! podemos ejecutar
comandos del sistema operativo dentro de mdb.

10. OpenSolaris: Paginación
Ejemplo:
(root@carlos)# mdb ­k
Loading modules: [ unix krtld genunix ip usba ipc random nfs ptm
> ! pagesize ­a
8192
65536
>
 El tamaño de página por defecto es 8K, aunque podemos disponer de
páginas de 8K,64K, 512K y 4MB, el tamaño de página se define en el
momento del arranque, por lo que no se puede cambiar en caliente,

11. OpenSolaris: Segmentación
 Al menos existen 4 segmentos: Texto, Datos, Heap, Pila.
 MDB nos ayuda para conocer los distintos segmentos que están asignados
al espacio de direcciones de un proceso. Para nuestro ejemplo crearemos un
nuevo proceso lanzando el comando sleep 50000 en background.[1] 1788
(root@carlos)#
(root@carlos)# mdb ­k
Loading modules: [ unix krtld genunix ip usba ipc random nfs ptm ]
> 0t1788::pid2proc |::print proc_t p_as |::walk seg |::seg
SEG BASE SIZE DATA OPS
3007d839f80 10000 2000 3000863d598 segvn_ops
300881d6d38 20000 2000 3578600afe8 segvn_ops
3015579b128 22000 2000 3007d8469c0 segvn_ops

12. OpenSolaris: Segmentación
...
35785fea3a8 ff3a0000 2000 3578601aa38 segvn_ops
3007d8661b0 ff3b0000 2e000 3578dae20e8 segvn_ops
3007d842120 ff3ee000 2000 301b3697bb8 segvn_ops
30008602678 ff3f0000 2000 3578da37e90 segvn_ops
3578da9d5a8 ffbfe000 2000 3000369f590 segvn_ops
>
 En el sistema existen varios tipos de segmentos de memoria, dependiendo
de la funcionalidad para la que se crearon, así podemos encontrar
segmentos de tipo seg_map, seg_kmem, seg_dev o seg_vn, entre
otros. Todos los segmentos son de tipo struct seg y lo que los diferencia
entre ellos, es el tipo de operaciones y el tipo de dato al que apunta el
puntero del campo s_data, por esta razón, este campo es un puntero
void.

13. OpenSolaris: Semáforos
 En OpenSolaris existe un elemento llamado Sets de semáforos, el cual es
en realidad un grupo de semáforos, no existen los semáforos
independientes, es decir, cuando nuestra aplicación necesita un semáforo le
solicita al Kernel un Set de semáforos, el cual tendrá un número
determinado de ellos mediante la llamada a sistema semget(), que acepta
como parámetros una key que define al set de semáforos, el número de los
semáforos del set y los permisos que tendrá el set de semáforos

14. OpenSolaris: Semáforos
 En esta versión los límites de los semáforos los podemos aplicar a
proyectos o procesos. Para ver como están configurados los límites de
los semáforos mediante el control de recursos debemos utilizar el
comando rctladm.
(root@carlos_10)# rctladm ­l | grep sem
process.max­sem­ops syslog=off [ deny count ]
process.max­sem­nsems syslog=off [ deny count ]
project.max­sem­ids syslog=off [ no­basic deny count ]
(root@carlos_10)#

15. OpenSolaris: Caché
 Dependiendo del tipo de procesador con el que se esta trabajando, el
tamaño y número de niveles varía, así en el procesador como el
UltraSparc V+ existen 3 niveles en la jerarquía de cache.
 Nivel L1: Es la memoria más rápida con la que trabaja el
procesador, aunque presenta el inconveniente de su reducido
tamaño.
 Nivel L2: Es más lenta que la cache L1 aunque presenta la ventaja
que es mayor tamaño.
 Nivel L3: Es la cache más lenta y está situada fuera del chip, el
tamaño de esta cache en el procesador UltraSPARC V+ es de
32MB.

16. OpenSolaris: Intercambio
 El sistema de memoria virtual (VM) de Solaris utiliza una nueva capa,
denominada swapfs, que consiste en un sistema de archivos que gestiona
el área de swap, de tal forma que en el área de swap únicamente se
ocupará espacio cuando el sistema lo necesite y no cada vez que un proceso
realice una petición de memoria.
 Cuando un proceso solicita una cantidad de memoria, supongamos que
mediante la llamada malloc() realiza una petición de 16K, esto significa
que el sistema reservará 2 páginas de memoria (suponiendo que el tamaño
de la página sea de 8K), estas nuevas páginas deben tener asignadas a un
vnode, como el resto de páginas de memoria, estas nuevas páginas son
páginas anónimas por lo que el vnode debe ser el área de swap.

17. OpenSolaris: Intercambio
 El Kernel utiliza la capa de swapfs para gestionar la asignación de los
vnodes a las nuevas páginas anónimas que se creen, mientras una
página que ha sido solicitada no sea necesario llevarla al área de swap, no
tendrá asignado ningún espacio en dicho área.
 Algo que debemos tener claro para entender cómo funciona swapfs es lo
siguiente, swapfs trabaja con un espacio virtual de swap el cual
está compuesto por el espacio físico de swap, es decir, todos los discos
o ficheros que se hayan asignado al espacio de swap, mas toda la memoria
física del sistema que pueda ser paginable. Es decir swapfs además de
utilizar los ficheros o discos que hayamos asignado al área de swap,
también utilizará toda la memoria disponible en el sistema.
 Espacio virtual de swap = Espácio de swap + Memoria física

18. OpenSolaris: Deadlocks
 OpenSolaris proporciona varias herramientas que permiten garantizar que
un dato solo es accedido por un thread o por varios pero teniendo solo uno
de ellos acceso como escritura.
 El bloqueo mas comúnmente usado es el de exclusión mutua (mutex),
dando acceso de lectura y escritura a un único thread.
 Cuando vayamos a acceder para leer o modificar un dato, por ejemplo la
lista de una cola de ejecución, podemos encontrar que su bloqueo se
encuentre libre o ocupado: Si el bloqueo se encuentra libre, nos
adueñaremos de el, realizaremos las acciones oportunas, y lo liberaremos de
nuevo.
 Si el bloqueo está ya ocupado se usa: Spin Mutex o Mutex Adaptive

19. OpenSolaris: Hilos
 OpenSolaris es un sistema multithread donde cada uno de los hilos de un
proceso puede tener una prioridad distinta, además esta es dinámica, es
decir durante su vida puede variar en función de varios parámetros, como
pueda ser la carga el sistema, como interactúe con otros hilos.
 Cuando un threads es creado en Solaris se asigna a una scheduling class,
para que nos entendemos esta define el rango de prioridades en el que
fluctuará durante su vida. Existen 6 rangos distintos:
 Timeshare (TS): Es la scheduling class por defecto, la prioridad del hilo
aumenta a medida que va esperando un cpu libre, una vez consiga cpu se
ejecutará hasta que se agote su quantum.

20. OpenSolaris: Hilos
 Interactive (IA): Parecida a la anterior, para entornos de escritorio, los
threads correspondientes a los procesos X window reciben un incremento de
prioridad.
 Fair Share (FSS): El tiempo de cpu se divide en unidades llamadas shares,
cada thread puede consumir x shares dependiendo del número de threads que hay
en esa scheduling class, de su consumo reciente y de su prioridad.
 Fixed Priority (FX): El thread tiene las misma prioridad durante todo su
ciclo de vida.
 Real Time (RT): Es el rango de prioridades altas, garantiza el mínimo tiempo
de lantencia entre que el thread pasa a estado running hasta que se le asigna
CPU.
 System (SYS): Es la clase usada para los threads del kernel, tiene prioridad
superior a las demás excepto la Real Time.

21. Créditos
Grupo de Trabajo:
Alvarado Pablo
Coronel Brayann
Peralta Diego
Román Carlos