|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
FAQ de linux-kernel | suscribirse a linux-kernel | Archivos de linux-kernel | kernelnotes.org | Navegador de Código del Núcleo Linux LxR | Todos los Núcleos | Núcleos Transportados | Documentos del Núcleo | Enciclopedia de Gary: Núcleo Linux | #kernelnewbies
Table Of Contents
| 1. | 7 Jul 2001 - 17 Jul 2001 | (13 posts) | Generalizando El Soporte Al Fichero De Intercambio En 2.5 |
| 2. | 16 Jul 2001 | (8 posts) | Agregando una entrada HZ a /proc/sys/kernel |
| 3. | 16 Jul 2001 - 17 Jul 2001 | (4 posts) | Colgado De e2fsck En 2.4.7 |
| 4. | 17 Jul 2001 - 18 Jul 2001 | (12 posts) | Esfuerzos De Documentación Del Núcleo |
| 5. | 17 Jul 2001 | (13 posts) | Información De Caché Para Durones |
Mailing List Stats For This Week
We looked at 1498 posts in 6286K.
There were 538 different contributors. 237 posted more than once. 139 posted last week too.
The top posters of the week were:
1. Generalizando El Soporte Al Fichero De Intercambio En 2.5
7 Jul 2001 - 17 Jul 2001 (13 posts) Subject: "RFC: Remove swap file support"
Summary By Zack Brown
People: Eric W. Biederman, Chris Wedgwood
Jeff Garzik sugirió que, ya que cualquier fichero podía ser convertido en un dispositivo de bloques a través de loop, no habría necesidad de dar soporte explícitamente al caso especial de ficheros de intercambio. Él propuso deshacerse del soporte para ficheros de intercambio en 2.5, y permitir que la funcionalidad equivalente sea hecha con loop.
Algunas gentes sugirieron que loop no era lo suficientemente estable para contar con él para hacer swapping. En otro lado, Eric W. Biederman discutió sobre si el código de fichero de intercambio aún era necesario. Dijo:
Sí, y no. Yo diría que lo que necesitamos hacer es actualizar rw_swap_page para que use directamente las funciones de espacio de direcciones. Con los dispositivos de bloque y los ficheros yendo a través del caché de páginas en 2.5 eso debe eliminar limpiamente cualquier caso especial.
En 2.4 el código de swap realmente no ha sido actualizado, el código antiguo solamente ha sido parchado lo suficiente para que funcione en 2.4. Esto agrega capas de trabajo que realmente no necesitamos estar haciendo. El eliminar la redirección extra tiene el potencial de dar un pequeño impulso de rendimiento al swapping.
El caso para cuidarnos es con bloqueos haciendo cosas como usando ficheros de intercambio en un montaje NFS. Como señalas ya podemos hacer esto con los dispositivos de loop back así que realmente no es un caso especial. El único caso nuevo que puedo ver funcionando son ficheros de intercambio con agujeros en ellos, o ficheros de intercambio que hagan compresión automática. Dudo que esos casos sean mejoras significativas pero parece como que caerán naturalmente.
Chris Wedgwood pidió la confirmación de que los dispositivos de bloque realmente pasarán a través del caché de páginas en 2.5, diciendo, "Yo había esperado que lo hicieran, que cualquiera de los dispositivos de bloques sean sólo vistas del caché de páginas de los dispositivos de caracteres soportados, por lo tanto permitiéndonos eliminar el caché de buffers y las cosas de /dev/raw." . Eric replicó (admitiendo que podría resultar que estuviera equivocado):
Los dispositivos de bloques irán a través del caché de páginas en 2.5. Tomará un rato para que se vaya completamente el caché de buffers, pero está ahí para las rutas de código que aún no han sido actualizadas. Las cabezas de buffers se quedarán.
Las cosas de /dev/raw es para aquellos usuarios que no quieren que el núcleo haga caché de sus datos y continuará existiendo en alguna forma.
2. Agregando una entrada HZ a /proc/sys/kernel
16 Jul 2001 (8 posts) Archive Link: "PATCH: /proc/sys/kernel/hz"
Summary By Adam Buchbinder
People: Rolf Fokkens, Ulrich Drepper, Andreas Jaeger
Rolf Fokkens publicó un parche pequeño y dijo "Algún software (como procps) necesita la constante HZ en el núcleo. Es determinada a veces contando los instantes durante un segundo. El parche adjunto tan sólo "publica" la constante HZ en /proc/sys/kernel/hz." Ulrich Drepper preguntó:
que hay de malo con
getconf CLK_TCK
o programáticamente
hz = sysconf (_SC_CLK_TCK);
Actualiza tu libc y esta información vendrá del núcleo.
Rolf dijo que eso no funcionó -- "dice 100 mientras que yo lo cambié en mi núcleo a 1024."
Andreas Jaeger dijo "tu núcleo está roto, revisa AT_CLKTCK" . Rolf concluyó que "para algunas arquitectura de hecho _sí_ hay una relación entre CLOCKS_PER_SEC y HZ, y para algunas _no_ la hay" [...] "Para i386 la relación _está_ ahí aparentemente. En cambio para IA64 está la suposición de que la relación _no_ está ahí, el núcleo asume que es 100 HZ para ia32 _siempre_. Raro" , y el hilo de discusión terminó algo inconcluso.
3. Colgado De e2fsck En 2.4.7
16 Jul 2001 - 17 Jul 2001 (4 posts) Archive Link: "2.4.7-pre6 can't complete e2fsck"
Summary By Adam Buchbinder
People: Gianluca Anzolin, Andrea Arcangeli
Gianluca Anzolin reportó problemas con 2.4.7-pre6aa1: "e2fsck /dev/hda3 nunca termina: no puedo siquiera detener el proceso con CTRL+C. Alt+SysRQ funciona y me dice que se incrementa el número de páginas sucias inactivas, mientras que las páginas activas y libres decrecen." Andrea Arcangeli sugirió que revertiera el parche "40_blkdev-pagecache-5". Después Andrea explicó más extensamente:
Ok, fue porque desarrollé los parches blkdev-pagecache y 00_drop_async-io-get_bh-1 en dos árboles separados.
Cuando ambos parches pasaron todas las pruebas de regresión los mezclé ambos en 2.4.7pre6aa1 pero desafortunadamente ningún rechazo me recordó que tenía que quitar el get_bh del manejador asíncrono utilizado por el caché de página blkdev (¡lo siento!).
Andrea incluyó un parche de dos líneas. Kurt Garloff reportó que él tenía el mismo problema, y que el parche lo compuso para él. El hilo de discusión terminó ahí.
4. Esfuerzos De Documentación Del Núcleo
17 Jul 2001 - 18 Jul 2001 (12 posts) Subject: "Kernel Documentation"
Summary By Zack Brown
People: Charles Samuels
Charles Samuels publicó un URL a algunos documentos que él había trabajado, para proveer descripciones de API de varias funciones del núcleo. Pidió ayuda incluyendo información de todas las funciones exportadas. Ignacio Vazquez-Abrams sugirió usar DocBook en lugar de XML plano, pero Charles replicó, "DocBook es más "librero" completo con capítulos y todo. Lo he usado antes, está bien, pero para esto, en mi opinión. También, el extremo detrás sólo mueve los datos XML a una base de datos temporal MySQL para búsqueda fácil, y ordenamiento, y algo como eso, pienso, sería mucho más difícil con docbook." Wichert Akkerman señaló que DocBook sería XML, pero no hubo respuesta.
En otro lugar, Crutcher Dunnavant señaló que ya había un proyecto en camino para documentar las APIs del núcleo. Él también anunció su propio esfuerzo de documentación para cubrir las mejores prácticas para hackeo del núcleo. Añadió que la ayuda sería bienvenida, y que las gentes debían estar prevenidas de que el documento estaba en las etapas muy tempranas. John Levon también dió un vínculo a la documentación existente de API.
5. Información De Caché Para Durones
17 Jul 2001 (13 posts) Archive Link: "2.4.6-ac5 gives wrong cache info for Duron in /proc/cpuinfo"
Summary By Adam Buchbinder
People: Christian Borntreger, David Balazic, Ketil Froyn, David Woodhouse, Alan Shutko
David Balazic, corriendo 2.4.6-ac5 en un Duron AMD 700, reportó que /proc/cpuinfo reportó un caché de tamaño 64K, cuando él sabía que el Duron tiene 192K de caché: 64 L1 I, 64 L1 D, 64 L2 unificado.
Christian Borntreger dijo "Hasta donde yo sé los Durones más viejos tienen un bug. Reportan un tamaño erróneo para el caché." Pero David señaló que "Los mensajes del núcleo al arranque no tienen problema para encontrar la información de caché correcta." En otro lugar Christian conjeturó que sólo el tamaño del caché de segundo nivel estaba siendo reportado en /proc/cpuinfo. David replicó que "debería decir "tamaño de caché L2:" Es un bug en cualquier caso." El cuerpo del subhilo terminó aquí.
En otro lugar, hubo un debate sobre la abreviación adecuada para `kilobytes'. Ketil Froyn sugirió consultar en acronymfinder.com, diciendo que las abreviaciones adecuadas eran "'K' para 1024, 'k' para 1000 y 'B' para bytes y 'b' para bits" . En un punto, David Woodhouse dijo, "El prefijo correcto para significar un múltiplo de 1034 es 'Ki'" , y publicó un parche para hacer el cambio. Unos cuantos mensajes después, Alan Shutko opinó que 'Ki' era "un nuevo estándard razonable que no había sido adoptado, porque mucha gente piensa que "kibibyte" es estúpido."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |