Alguien sabe porque en el top me aparece el pid del top y del loop
pero haciendo un less -F /proc/sched_debug y luego buscando el pid (ates de que loop de exit) /"NROdlePID" no me lo encuentra y al pid del top si
cabe aclarar que tambien lo busque por el autogroup-NRO que coincide con el del bash padre del top y del loop&
http://lxr.free-electrons.com/ sitio util para ver kernel/sched/debug.c y tratar de entender como funcan las filas
Xq tirando un grep -R -H "exec-runtime" /usr/src/kernels/ o algun otro cabezal salta solo binay files
Ahí te aparece el archivo debug.c, no se por que decís que solo te aparecen archivos binarios.
grax xq si era un ofidio me picaba :P (no lo vi)
En fin (despues en el bus me pregunte xq no aparecia, como compile el kernel supuce que seria algo exterior x sino apareceria, pero despues me avive que tenia que modificar el codigo por los arboles, asique... bueno estaba nomas)
en cuanto al significado de las columnas estoy intentando ver que significa tree-key (se supone que el nombre se deberia de autoexplicar pero.. ) que corresponde a p->nvcsw + p->nivcsw ... Ok esta dentro del propio .c.
Lo que no me queda claro es que tiene que ver "llave de arbol" o "clave de bifurcacion" con nr_switches que para mi es la cantidad de cambios de contexto ya sea por I/O o interrupt.
Imagino que cuando hablan de la ultima columna, se refieren a la ultima columna "visible" (en cuyo caso serian 3 en funcion de los ifdefines)
De las ultima 3 la ante penultima sum_sleep_runtime Imagino que es el tiempo que el proceso esta esparando para pasar a ser current, mientras esta en "runtime" o sea corriendo. Mi pregunta es si se cuenta cuando esta en la ready queue y R/W queue tambien, o si solo se cuenta cunado lo interrumpen. Imagino que se cuenta TODO el tiempo que no ejecuta (NO usa CPU ya sea xq esta en I/O burst o CPU burst pero interrumpido o preempteado por el scheduler)
y la penultima:
Tiene algo que ver con el cpuset??? el task_node
llama al cpu_to_node(task_cpu(p));
return task_thread_info(p)->cpu;
http://man7.org/linux/man-pages/man7/cpuset.7.html
http://man7.org/linux/man-pages/man3/numa.3.html
En cuanto al ultimo (que tal vez sea el que va) aun no lo mire muy bien. pero por lo que busque saltaba algo de agrupamiento automatico de task por sesion. No entendi (obvio) y mirando estructura de task_group vi que tiene un parent lista de children lista de siblings;
En fin me pregunto si cuando salis del mismo padre estas en la misma sesion que tus children y sibling? o si podes agrupar como se te cante (no tan auto) o que es lo que le planificdor considera mas apropiado.
El path no se, te lo debo sera la direccion de memoria donde esta la estructura...
Hay algun lugar donde te explique como se usa esa estructura
Salu2
Diferencia en docu
http://lxr.free-electrons.com/source/include/linux/rbtree.h?v=2.6.35
ahi este al isRead
VS
http://lxr.free-electrons.com/source/include/linux/rbtree.h
aca no Xq???
En fin me surge la duda de cual nodo RB dentro de la estructura task_struct (http://lxr.free-electrons.com/source/include/linux/sched.h) uso?
#ifdef CONFIG_SMP 1404 struct plist_node pushable_tasks; 1405 struct rb_node pushable_dl_tasks; 1406 #endif
#ifdef CONFIG_RT_MUTEXES 1566 /* PI waiters blocked on a rt_mutex held by this task */ 1567 struct rb_root pi_waiters; 1568 struct rb_node *pi_waiters_leftmost; 1569 /* Deadlock detection and priority inheritance handling */ 1570 struct rt_mutex_waiter *pi_blocked_on; 1571 #endif
Ta la version que tengo del rbtree.h aca no tiene los macros.... ni los ejemplos XQ??? Ahh xq estan en la V 2.6 y yo tengo la 4.1 Que Oscurantistas!! le sacaron los macros y los ejemplos comentados... uuuu ojo no vaya a ser que uno entienda y se ponga a desarrollar en el kernel :D capas que los dejamos sin hobie :P
Ta le pase por arriba con los macros viejos a ver si funca...
Rebento
Ojo capas es por esto:
To use rbtrees you'll have to implement your own insert and search cores.
This will avoid us to use callbacks and to drop drammatically performances.
I know it's not the cleaner way, but in C (not in C++) to get
performances and genericity...
See Documentation/rbtree.txt for documentation and samples.
Como mi ingles no es very good looking podria ser eso (claro que son macros no insert y search y en la docu no estan los macros)
.....
Paso nomeclator y chau le encajo un sablazo a rb_parent_color y lo cambio a __rb_parent_color (¿que los motivo a esto? debe de haber una convencion donde __ adelante de un atributo signifique algo que desconozco) Aguante el oscurantismo!! y la ingnorancia que hace que todo parezca magia :D
.....
Ta ta mal yo (mis apologises) estos tipos son kaaapos movieron los macros y cosas que al meter rebentaban a rbtree_argumented manteniendo backwardcompatibility con los macros ya que ahora tambien se les ocurrio ponerle __ a __rb_is_black onda wraper. (lastima que eso no esta documentado en el .txt)
Algun dia seremos asi de grandes :D
Es posible que te de todos RED??? Me imagino que no xq sino donde quedo el balanceo. Asique mi if "sobre pushable_dl_tasks" debe de dar siempre false
Bien el sched entity "se" runing node se ve que tampoco es porque me dan todos black
Si tenés dudas donde está representado el nodo del árbol en el task_struct fijate en las diapositivas de planificación que allí lo dice.
Ok gracias ya corrobore en las ppts(no es el nodo pushable).
me surge la duda de si esos son "todos" red por "casualidad"(o no me di cuenta que hay negros) o si tiene algo que ver con
pushable_dl_tasks_leftmost???
en una configuracion sin hojas izq.
B
/ \
R R
\ / \
B B B
talvez tendria que hacer un printRBTree si es que ya no hay uno implementado... los hay como datatype RBTree pero no veo que toquen estructuras del kernel... severla si hay tiempo de hacerlo.
Hay algo "grafico" aunque sea basico que te muestre como se "mueve el kernell" por lo menos los procesos dentro de las estructuras tipo top, pero que te muestre las queu y las cpus y los trees.
algo onda zenmap para nmap???
Ok hay algunos RED solo de los procesos que se suponen son "polenta" (aunque prio 120 tienen un monton)
Ya me hice un script "onda top" que me muestra el balanceo imagino que esta bien de donde saco el nodo (PD me fije en la diapo, pèro me fijo otra vez igual por si no es el "se").
En fin pasa de RED a BLACK solo que esta en BLACK mas tiempo que en RED para un proceso dado que compite con otros por ejemplo. para unos 50 pings xej (no use CPU bust).