Libertonia || ¿Que rama del kernel usas?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

¿Que rama del kernel usas?


Anticuado, la 2.7.x que he empezado a desarrollar yo mismo.	0 votes - 0 %
La última 2.6.4	8 votes - 34 %
2.6.x pero no la última	6 votes - 26 %
2.4.x	9 votes - 39 %
La que trae mi distribución	0 votes - 0 %
2.2	0 votes - 0 %
1.x	0 votes - 0 %
Neuróticos, sin con la 0.x sobra y basta.	0 votes - 0 %

23 Total Votes

¡Corre eh! | 5 comentarios (5 temáticos, editoriales, 0 ocultos)

Detalle (5.00 / 1) (#1)
por Notup a las Wed Mar 24th, 2004 at 03:30:08 PM CET
(Información Usuario)

Se me olvido un pequeño detalle que hay que añadir en el cambio del kernel.

Si un editor tiene a bien añadir el siguiente párrafo a continuación de cuando termino de explicar el asunto de la emulación scsi y luego borrar este comentario, pues bien, si no que se quede aquí:

---añadido---

Otro problema que se plantea es que los sensores no funcionan.

Por pereza y ya que estan compilados en el núcleo me omito bajar las fuentes de i2c y lmsensors tal y como las tenía instaladas antes y procedo a instalar el paquete actualizado por Adrian Bunk, no hace falta añadir linea a sources.list se incluye el paquete con la que ya cité anteriormente.

apt-get install lm-sensors.

Empieza el show

Como punto número 1 hay que añadir lo siguiente al /etc/fstab (y obviamente crear el directorio /sys)

sysfs /sys sysfs defaults 0 0

Y además contra lo que reporta el sensors-detect y mi configuración anterior no hay que añadir el módulo i2c-viapro, porque entonces no funciona en mi placa, sólo se debe cargar i2c-isa y via686a.

---Fin del añadido---

CONFIG_PREEMPT. ¿sí o no? (4.00 / 1) (#2)
por atopos a las Wed Mar 24th, 2004 at 05:48:14 PM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Como último apunte reseñar que en base a las lecturas apresuradas que hice para resolver algún que otro problema decidí no usar preempt.

Desde luego, si se quiere estabilidad, parece en este momento lo más aconsejable; y práticamente obligado en el caso de arquitecturas powerpc (como la que yo uso).

Por si alguien quiere saber más sobre qué es lo que opinan hoy por hoy alguno de los principales desarrolladores del kernel, puede ser interesante este vínculo:

Kernel Preemption, To Enable Or Not To Enable

CONFIG_PREEMPT en powerpc (none / 0) (#4)
por atopos a las Thu Mar 25th, 2004 at 09:09:38 PM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Sólo como matiz de mi anterior afirmación sobre este tema en los powerpc, añado que, justo hoy, Ben Herrenschmidt, programador particularmente implicado en la creación de parches para esta arquitectura, acaba de enviar un mensaje a la lista debian-powerpc comentando que está empezando a fijarse en las cuestiones relacionadas con la ejecución de kernels con la citada opción activada.

Habrá, pues, que esperar a ver los resultados que se obtienen en el futuro próximo como consecuencia de tales desarrollos.

[ Padre ]

Completando en link de kerneltrap (4.00 / 1) (#3)
por ridiculum a las Wed Mar 24th, 2004 at 11:49:37 PM CET
(Información Usuario)

A raiz de todo el tema este de la preemtividad y la no mejora del peor caso en las latencias ha surgido un hilo bastante interesante en la lkml:RCU for low latency (experimental).

El parche creo que lo ha hecho un desarrollador de alsa y consigue una reduccion del 50% en el planificador (de 800ms a 400ms). A parte de eso, tambien citan un estudio sobre latencias en el kernel 2.6.0.

Parece que el tema de la preemtividad solo ha conseguido disminuir la latencia media, cosa que no es mala para el uso tipico de los PC's, pero el peor caso no ha conseguido mejorarlo, cosa que es mala para tareas de como el procesado de video o audio.

A ver si estos estudios llegan a buen puerto e introducen los parches que han creado para mejorar este aspecto.

Sobre el rendimiento del kernel 2.6, he visto algunos comportamiento raros a la hora de cerrar archivos:

strace -r -o log mutt

     0.000082 open("/home/raul/mail/ecolnet", O_RDONLY) = 4
     0.000079 fstat64(4, {st_mode=S_IFREG|0600, st_size=11557354, ...}) = 0
     0.000067 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x402c2000
     0.000045 read(4, "From raul  Thu Apr 24 01:37:13 2"..., 4096) = 4096
     0.648405 close(4)                  = 0

12M 2004-03-24 22:18 mail/ecolnet

Ese close tarda mas de medio segundo y algunas veces tarda mas. No se si es culpa de alguna regresion en el fs (uso ext3), en la parte del IDE, o en donde, pero ese tiempo no es normal. A parte de eso, no tengo muchas mas quejas por el comportamiento general de este nucleo.

PD: En la rama -mm ha entrado una variante del exec-shield de Ingo Molnar.

Columpiada :) (none / 0) (#5)
por ridiculum a las Fri Mar 26th, 2004 at 05:39:41 PM CET
(Información Usuario)

El señor del hilo que cito no curra en la parte de alsa, sino que curra en IBM y precistamente el parche que ha enviado es para el RCU, una de las supuestas tecnicas robadas del UNIX de SCO.

El desarrollador de alsa aparece en el hilo que cita atopos y es Takashi Iwai. El hilo es bastante interesante y se puede leer aqui.

Comentan algunas mediciones de este señor, y tambien hay (o debe hacer) algun enlace a la suite con la que hizo para medir las latencias.

[ Padre ]

¡Corre eh! | 5 comentarios (5 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda