Tráfico del Núcleo #118 For 14 May 2001

There were 445 different contributors. 211 posted more than once. 148 posted last week too.

Pavel Machek publicó un parche para hacer saber a init que el botón de encendido había sido presionado, y así podía cerrar el sistema airosamente. Andrew Grover objectó, "Esto no es correcto, porque queremos que el botón de encendido sea configurable. El usuario debería ser capaz de redefinir la acción del botón de encendido, tal vez para sólo poner a dormir al sistema. Actualmente mostramos eventos del botón a acpid, que entonces puede hacer lo correcto, incluyendo un shutdown -h now (el cual asumo que notifica a init)." Pavel replicó, "No hay problema con la configurabilidad -- puedes configurar init también. Lo ví muy análogo con la situación de Ctrl-Alt-Del: también envía señales a init. Entonces init decide qué hacer. [Creo que no es necesario requerir acpid para una cosa tan fácil...]" Pero John Fremlin señaló, "Usar una señal para darle a init es un poco dudoso porque la mayoría de las señales ya están enganchadas para algo más. Por ejemplo, si se envía SIGTERM a mi init (http://john.snoop.dk/programs/linux/jinit) apagaría y comenzaría sulogin, lo cual probablemente no es lo que quieres cuando presionas el botón de encendido." En otro lado, Miquel van Smoorenburg agregó, "SIGTERM es una mala elección. Justo ahora, init ignora SIGTERM. Por una buena razón; en algunos (¿muchos?) sistemas, los guiones de apagado incluyen "kill -15 -1; sleep 2; kill -9 -1". El "-1" significa "todos los procesos menos yo". Esto significa que init será golpeado ocasionalmente con SIGTERM durante el apagado, y esto podría causas que sucedieran cosas raras."

Mike Castle sugirió que tal vez debía haber un mecanismo especial para permitir que el espacio de usuario se comunique con el núcleo, para manejar todas estas situaciones. Pavel replicó, "init _es_ la herramienta que es correcta para definir la política en tales asunto. Echa un vistazo sobre cómo es manejado la administración de UPS."

Ahí continuó una discusión larga y tortuosa en lo correcto e incorrecto de varias políticas y configuraciones; pero ninguna decisión concluyente salió de eso.

Peter Osterlund reportó que bajo carga de fork, 2.4.4 parecía ser menos responsivo que 2.4.3. Dijo, "Por ejemplo, cuando corro el guión configure de gcc, el apuntador del ratón en X es bastante espasmódico. El guión configure por sí solo corre aproximadamente tan rápido como en 2.4.3. Otra cosa es que no es posible interrumpir el ciclo de bash "while true ; do /bin/true ; done" con ctrl-c. Una tercera cosa que he notado es que iniciar una sesión gnome en redhat 7.0 toma más tiempo. (Toma más tiempo para que aparezca la pantalla inicial de gnome.)" Atribuyó esta conducta al parche reciente, que causa que los hijos corran antes que los padres después de un fork; y publicó un parche para revertir esa característica. J. A. Magallon no pudo confirmar el problema, pero Mohammad A. Haque dijo que él había visto también la misma conducta. Rene Puls también reportó conducta idéntica, y encontró que el parche de Peter lo componía.

En un punto, Linus Torvalds dijo, "El nuevo acercamiento "corre el hijo primero" tiene ventajas, pero es enteramente posible que las ventajas pongan prioridad injustamente en cosas que hacen mucho fork." Él y muchos otros señalaron que el ciclo while de Peter era sólo un bug de bash. Pero coincidió que definitivamente había un problema. Dijo, "Revertirlo en este momento puede ser un acercamiento aceptable. Pensaré sobre eso: los argumentos _para_ el parche son verdaderos y reales, y muestra mejoras reales en algunas cosas.. Una solución alternativa sería no dar al hijo el fragmento de tiempo _completo_, pero darle más de la mitad. Particionarlo 66% - 33% o algo así."

H. Peter Anvin publicó un parche, y explicó, "Estaba revisando el código de iso9660, y noté que estaba haciendo conversión de endianess a través de *funciones* ad hoc, ni siquiera inlines; ni tomaba ninguna ventaja del hecho de que iso9660 es bi-endian (tiene "todos" los datos en formato bigendian y littleendian.) El parche adjunto compone ambos. Es contra 2.4.4, pero por la forma de éste debería parchar contra -ac también." Martin Dalecki emitió una palabra de advertencia, "Por favor ten cuidado: Estás abriendo una lata de gusanos aquí, ya que hay tantos programas productores de CD rotos por ahí, que solamente proveen los datos little endian y entradas big endian incorrectas. Yo mismo he tenido algunos CD's de esta forma. Así que la neutralidad de endian de iso9660 está presente sólo en la teoría..." Pavel Machek remarcó con una sonrisa socarrona, "Sería divertido crear *deliberadamente* diferentes sistemas de ficheros; uno con un lado little endian y uno con un lado big endian. De esta forma los usuarios de windows verían que "las macs apestan" y los usuarios mac "las PCs apestan", y eso con un sólo cd ;-)."

Andreas Rogge quiso crear 100,000 buzones de correo en un directorio, sólo para encontrar que después de 32768, el directorio se negó a crear nuevos subdirectorios. H. Peter Anvin replicó que él creía que 2^15 directorios en un solo directorio era una limitación de ext2. Andreas Dilger replicó:

Está impuesto por cierta cantidad de detalles:

EXT2_LINK_MAX=32000 es revisado por nuevos subdirectorios
bg_used_dirs_count de ext2 es un __u16
inode->i_nlink (__kernel_nlink_t) es un unsigned short para algunas plataformas

Para stat (intefaz antigua) la cuenta st_nlinks también es un unsigned short, así que _podemos_ ser capaces de incrementar EXT2_LINK_MAX a 65500 o algo así de forma segura. El VFS tendrá problemas si incrementas la cuenta máxima de enlaces arriba de 65535 porque __kernel_nlink_t es __u16.

Veo que reiserfs juega algunos trucos con la cuenta de directorio i_nlink. Si excedes 64536 enlaces en un directorio, se revierte a "1" y ya no lleva más la cuenta de enlaces.

Tendrás problemas con el rendimiento para directorios de este tamaño en ext2 estándard, a menos que uses el parche de directorio indizado de Daniel Phillips. He probado 100k+ _ficheros_ en un solo directorio sin problemas (Daniel ha probado 1M _ficheros_ sin problemas). NO recomendaría hacer esto en su servidor de correo en producción en este momento, pero puede al menos digno de probarse... No resuelve (aún) el asunto de muchos subdirectorios, pero es algo en lo que por lo menos se puede trabajar.

http://kernelnewbies.org/~phillips/htree/

Chris Mason confirmó las observaciones de Andreas D. en reiserfs, "La cuenta de enlaces no es usada al final cuando se decide si el directorio está vacío (usamos el tamaño en su lugar), así que podemos tan sólo mentir a VFS si alguien trata de hacer toneladas de subdirectorios." Andreas D. replicó, "En ese sentido, ext2 tampoco usa la cuenta de enlaces en los directorios para determinar si están vacíos, así que no debe ser muy difícil hacer lo mismo con el código de directorio indizado de ext2."

Ingo Oeser sugirió que cualquier aplicación que intente crear tantos directorios está completamente rota, pero H. Peter dijo, "La aplicación está usando la VFS en la forma en que está anunciado que funciona. Si piensas que hacer ls en un directorio extremadamente grande, nunca has visto las caídas de una aplicación que trata de hacer balanceo de cargas entre directorios haciendo hashing real. ¡ESO es doloroso! Por lo menos en el primer caso puedes usar grep."

Como no está permitido usar deferencia de memoria directa en áreas remapeadas en e/s, ¿no sería más lógico dejar que ioremap() regrese un unsigned long en lugar de un void *?

Por supuesto que entonces tenemos que cambiar readb() y amigos para que tomen también un long, pero al menos tendremos advertencias del compilador cuando alguien trate hacer una deferencia directa.

Mejor aún, me parece, su propio tipo. Digo: typedef unsigned long io_ref_t;

Ya está hecho para para dma_addr_t, y esto parece ser un caso análogo.

El trabajo más grande sería componer todas las deferencias directas (una cosa valiosa, supongo; una revisión rápida muestra por lo menos algunos), así como componer asignaciones sin cast de ioremap(). O idealmente deshacernos de los casts (la mayoría de los que veo son casts a unsigned long) y tipificar apropiadamente el buffer de recepción.

Sería un gran trabajo. Y Linus sugiere además que el primer argumento de ioremap sea un objeto específico a la arquitectura, no necesariamente una dirección física de CPU o una dirección PCI (aunque típicamente son ambos en muchas (la mayoría) de las implementaciones i386. De hecho *debe* haber una limpieza.

Hubo algo de discusión de varias posibilidades, y en un punto David S. Miller remarcó, "Supongo que hay una línea delgada escrita al usar APIs para influir en la gente para que "haga lo correcto", y esto ha sido ejemplificado en varios hilos de discusión donde he estado involucrado en escribir dma PCI y otros temas. :-)"

Nico Schottelius publicó un parche para crear una opción de compilación para desactivar la bocina en la PC. Simon Richter dijo que estaría bien si esto fuera configurable en tiempo de ejecución a través de algo como sysctl. Keith Owens dijo que todo el problema era de espacio de usuario, ya que tanto setterm como xset podían desactivar la bocina. Pero Oystein Viggen replicó, "Bueno, a algunos programas con bugs no les importa que apages el bip en X. Pienso que gnome-terminal o algún otro tiene su propia opción para activar o desactivar los bips." Nico dijo que él también pensó primero que el problema era sólo de espacio de usuario. Pero también coincidió con Simon, que una opción en tiempo de ejecución sería lo mejor de todo. Preguntó dónde podía encontrar documentación de sysctl, pero nadie dio ningún vínculo.

Pueden encontrar una nueva versión del parche de cpu hot swap en:

http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch

La versión para s390 (necesitan aplicar primero el parche para el núcleo 2.4.3 disponible en el sitio web de Linux en IBM s390) está en:

http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch-s390

Muchas gracias a Heiko Carstens <Heiko.Carstens@de.ibm.com> por agregar soporte a s390 y componer algunos bugs en la implementación inicial. Deberían poder conectar y desconectar CPUs dependiendo de la carga de trabajo en sus imágenes hospedadas de Linux en s390 :)

Una de las ventajas de este parche es que elimina cpu_logical_map() y cpu_number_map() para los cuales la gente tenía una tendencia para tenerlos mal.

También debe ser fácil dar soporte a más de BITS_PER_LONG cpus ya que el concepto de online_cpu_map ya no está más.

Dwayne C. Litzenberger comenzó a salivar sobre el piso, y preguntó, "¿Qué tan lejos está la capacidad para "teletransportar" procesos de una máquina a otra sobre la red? ¡Piensen en el tiempo de actividad!" Unas cuantas gentes le señalaron hacia MOSIX, pero Jakob Ostergaard replicó que actualmente MOSIX no daría grandes tiempos de actividad debido a la migración de procesos. Él señaló que los procesos en los clusters MOSIX siempre estaban atados a su nodo inicial, y que moririá sin importar qué tan lejos hubieran migrado, si el nodo inicial moría. Bruce Harada dió un apuntador a Migración de Procesos Heterogéneos: El Sistema Tui.

No hubo respuesta a eso, pero en otro lado, Peter Rival preguntó cuando sería soportado el hot-swap o la adición en caliente de RAM, y Chris Wedgwood replicó, "Probablemente la adición de memoria no vaya a ser muy difícil... pero sacar fuera de línea a la memoria existente tiene trucos. Tienes que encontrar alguna forma de encontrar todas las páginas que están en uso y entonces lidiar apropiadamente con ellas, y yo pensaría que esto sería extremadamente difícil cuando alguna estuviera bloqueada o contuviera datos del núcleo." Después él agregó, "Es difícil con los paradigmas actuales de administración y alojamiento de memoria, si quisieramos abstraer las cosas más y más (rompiendo) ciertas reglas, estoy seguro que me puede hacer trabajar -- la única cosa es, perderíamos _MUCHA_ velocidad y eficiencia (y desperdiciaría mucho más espacio), así que dudo que alguien seriamente quiera saber acerca de esto. También tendríamos que violar ciertas suposiciones de las aplicaciones RT."

En un punto, Rik van Riel dijo que quitar RAM en caliente realmente no sería tan difícil, porque:

1. el núcleo usa en sí memoria virtual y accesa sus estructura de datos a través de tablas de páginas

2. revertir las cosas de mapeo es fácil (a pesar de que cuesta 8 bytes de sobrecarga por apuntador mapeado, duplicando probablemente el costo de la tabla de páginas)

Esto sólo deja dos pendientes, el primero son los controladores de dispositivos y el segundo es la cuestión acerca de que si queremos el costo necesario para implementar la reubicación (bastante sencilla) de memoria.

Chris preguntó cómo Rik manejaría la reubicación de páginas que estuvieran mlocked, sin violar restricciones de RT. Rik replicó, "A la mierda con las restricciones RT. Linux no tiene latencias de calendarización infinitamente pequeñas, es fácil copiar una página sin incrementar mucho las latencias de calendarización." David Woodhouse dio este punto de vista:

Tienes que copiar la página, entonces mapéala en la misma dirección virtual (ya sea de espacio de usuario o de núcleo) que la anterior. Marca la página como sólo lectura cuando comiences a copiarla, y ten un manejador de faltas que inmediatamente la marque como escribible y regrese. Si la fuente es escribible para el tiempo en que has terminado la copia, repetir.

Si tienes que repetirte a tí mismo más de $n veces, probablemente estás experimentando bloqueo vivo. En este punto, haz lo que Rik dice - al diablo con las restricciones RT, deshabilita interrupciones y haz la copia. Por lo menos tu caché está tibio :)

Esta es parte de mi lista de deseos para kdb, ¿algún fantasioso que escriba el código de cualquiera de estas características? Sería un buen proyecto para cualquiera que quiera comenzar en el núcleo. Respuestas a kdb@oss.sgi.com por favor. Parches actuales en http://oss.sgi.com/projects/kdb/download/

Cambiar la tecla de invocación de kdb de ^A a ^X^X^X en 3 segundos. ^A es usada por emacs, bash, minicom etc.
Historia de comandos. Manejar las teclas arriba/abajo/izquierda/derecha/borrar. Cada rutina kdba_io es responsable de reconocer las teclas específicas de la arquitectura, con una historia común y rutinas de edición.
Limpiar los comandos repetitivos. El presionar enter en el prompt de kdb repite el comando previo, sin importar cual era el comando previo. No tiene sentido repetir algunos comandos (bp en particular), para otros comando quieres repetir el comando pero sin el parámetro (md en particular).
Incluir opciones de ancho y cuenta en los comandos md y mm. Algún hardware requiere que los accesos sean de un ancho específico, esto puede ser logrado estableciendo BYTESPERWORD pero es torpe. Queremos que md1 lea un byte, comandos md2, md4, md8. Todos pueden tener un campo de cuenta, p.e. md1c8 lee 8 bytes uno a la vez. mm1, mm2, mm4, mm8 que establezcan cuenta de memoria no cuenta de campos.

Vamsi Krishna S. se ofreció como voluntario para trabajar en el punto 4. Tigran Aivazian sugirió agregar a la lista de deseos:

hacer posible (¡es trivial pero un dolor tener que hacerlo manualmente cada vez que actualizo a su última versión!) para que esos "módulos" extra sean enlazados estáticamente. Así para que uno no tenga que mantener esas líneas en el rc.local

if [ -f /proc/sys/kernel/kdb ]
then

insmod kdbm_pg > /dev/null 2>&1
insmod kdbm_vm > /dev/null 2>&1

y entonces descubrir que los módulos son de la compilación correspondiente a un ajuste diferente en page.h o highmem o lo que sea (dejadlo para aquellos que entiendan ;)

Hace algún tiempo sugerí eliminar completamente la infraestructura para esos "módulos" (con la justificación siendo -- no es inútil _únicamente_ en un caso verdaderamente exótico de enseñar a kdb nuevas características en un núcleo en ejecución sin permiso para reiniciar) pero han objetado y está bien, pero al menos hacerlo opcionalmente posible sería _muy bueno_, por favor.

No hubo respuesta a esto, pero Manfred Spraul también sugirió, "'ss' y especialmente 'ssb' pueden imprimir el nuevo valor de la dirección de registro/memoria en cada línea, tal vez tanto el valor antiguo como el nuevo." Keith exhortó a la gente a escribir código para los deseos actuales antes de agregar nuevos.

No hubo respuesta a esto, pero en otro lado, George Anzinger replicó al punto 1 de la lista original de Keith. Él señaló, "^X^X intercambia punto y marca en emacs. Uno (bueno, yo) haría ^X^X^X^X frecuentemente para examinar donde está la marca y después regresar a punto." Alguien sugirió usar la condición de interrupción en su lugar, y Juan Quintela replicó, "kdb usa BREAK en el puerto serial (que minicom use C-a para enviar un break es una anécdota :) Pero el problema a colgar es la consola. Voto por el ^X^X^X ya que pienso que no es un atajo difícil. (y sí, también uso emacs y ^X^X todo el tiempo, pero pienso que esta combinación no es particularmente mala, y supongo que las aplicaciones mascota de otras gentes tendrán problemas con algo como: ^A^A^A que nunca uso)."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	4 Apr 2001 - 27 Apr 2001	(79 posts)	Respuesta A Eventos De Apagado
2.	28 Apr 2001 - 3 May 2001	(21 posts)	2.4.4 Lento Bajo Carga De Fork
3.	30 Apr 2001 - 3 May 2001	(18 posts)	Limpieza de Endianess de ISO9660
4.	1 May 2001 - 5 May 2001	(14 posts)	Número Máximo De Directorios En Un Directorio
5.	2 May 2001 - 4 May 2001	(21 posts)	Diseñando API Para Estimular Buenas Prácticas De Programación
6.	4 May 2001	(6 posts)	Desactivando La Bocina De La PC
7.	5 May 2001	(20 posts)	Intercambio En Caliente De CPUs Y RAM
8.	8 May 2001	(10 posts)	Lista De Deseos Para KDB

Tráfico del Núcleo #118 For 14 May 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera