tag:blogger.com,1999:blog-507892079964167031.post9079068853195855469..comments2023-07-07T11:22:23.014+02:00Comments on make install . es: Optimizar el kernel Linux: MTRR cleanup supportAnonymoushttp://www.blogger.com/profile/09387646684121227737noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-507892079964167031.post-58243601369165952152012-02-07T01:26:51.125+01:002012-02-07T01:26:51.125+01:00Buen aporte, queria optimizar mi kernelBuen aporte, queria optimizar mi kernellaptop toshibahttp://www.laslaptops.infonoreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-91754530133238800602011-11-16T20:43:15.172+01:002011-11-16T20:43:15.172+01:00El ejemplo práctico que has tomado ni es real ni j...El <i>ejemplo práctico</i> que has tomado ni es real ni justo. Estas modificando el código fuente para alterar el comportamiento normal del kernel. En cualquier caso entiendo lo que quieres decir: que el kernel puede bloquear el uso de determinadas instrucciones del procesador, pero es algo normal e incluso el usuario puede puede desactivar una flag determinada en tiempo de arranque pasando el parámetro clearcpuid=XXX al kernel.<br /><br />Pero no lo considero un ejemplo válido, sino más bien una excepción. Una excepción que tiene sus motivos y que están documentadas dentro del propio código fuente del kernel. En él, los hackers explican que bloquean las instrucciones PAT en los procesadores X debido a un bug de dicha instrucción.<br /><br />Sin embargo es obvio que los programadores no supieron determinar que procesadores estaban afectados por dicho bug y decidieron inhabilitar la instrucción PAT en todos los modelos de procesadores anteriores a los Pentium 4 (modelo 15). Porque tal y como tu has dicho, has quitado el bloqueo, y actualmente usas PAT sin problemas.<br /><br />Respecto a la <i>triquiñuela</i> para mostrar NOPL como una flag válida, no deja de ser una triquiñuela, y eso no es lo que discutimos. No tiene sentido que modifiquemos el kernel para que informe que la cpu funciona a 100 Ghz y después afirmemos que el kernel informa mal de las especificaciones de la cpu.<br /><br />Las flags del procesador siempre aparecen en /proc/cpuinfo, sin necesidad de activar nada en el kernel aunque como tu mismo has demostrado existen <b>casos excepcionales</b> y algunas flags son bloqueadas y desactivadas a conciencia por los programadores del kernel por X motivos.<br /><br />De hecho te propongo una prueba para ver que las flags que aparecen en /proc/cpuinfo no las proporciona el kernel sino la cpu. Compila un kernel sin soporte para mtrr, arranca dicho kernel y comprueba las flags que arroja /proc/cpuinfo. Comprobarás que seguirá informando de que tiene soporte para mtrr, aunque el kernel no sepa qué es o que hacer con esa instrucción.<br /><br />Respecto a que tienes PAT activo, no cabe ninguna duda. Y con tu caso veo claro que he de dar más importancia a dmidecode. Ya que si existen discrepancias entre lo que dice dmidecode y lo que dice /proc/cpuinfo está claro que <i>algo raro esta ocurriendo</i>. E imagino que así es como te diste cuenta de que algo pasaba con las instrucciones pat de tu procesador. En cualquier caso <i>chapó</i> por ti, primero por darte cuenta (que es lo más difícil) y después por eliminar el bloqueo.Anonymoushttps://www.blogger.com/profile/09387646684121227737noreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-64907271598023947372011-11-16T18:36:04.934+01:002011-11-16T18:36:04.934+01:00Sí, dmidecode puede no informar acerca de todos lo...Sí, dmidecode puede no informar acerca de todos los flags (APIC por ejemplo no me lo muestra), pero de todos los que informa al menos sí que son flgags que la cpu tiene.<br /><br />Todo lo que explicas es una teoria muy bonita pero, cojamos un ejemplo práctico donde hago un par de cambios en el código del kernel (3.0):<br /><br /> sed -i "108s/15/8/g" arch/x86/kernel/cpu/intel.c<br /> sed -i "731s/clear/set/g" arch/x86/kernel/cpu/common.c<br /><br />Cambios que no fuerzan la habilitacion, ni son un "maquillaje" sino que simplemente impiden la desabilitación de estos flags. No tenia ni PAT ni NOPL en cpuinfo. Una vez hecha la modificacion y compilado el kernel tengo en mi viejo Pentium M tenemos lo siguiente:<br /><br /><i>cat /proc/cpuinfo <br />processor : 0<br />vendor_id : GenuineIntel<br />cpu family : 6<br />model : 9<br />model name : Intel(R) Pentium(R) M processor 1500MHz<br />stepping : 5<br />cpu MHz : 600.000<br />cache size : 1024 KB<br />fdiv_bug : no<br />hlt_bug : no<br />f00f_bug : no<br />coma_bug : no<br />fpu : yes<br />fpu_exception : yes<br />cpuid level : 2<br />wp : yes<br />flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov <b>pat</b> clflush dts acpi mmx fxsr sse sse2 tm pbe bts <b>nopl</b> est tm2<br />bogomips : 1199.05<br />clflush size : 64<br />cache_alignment : 64<br />address sizes : 32 bits physical, 32 bits virtual<br /></i><br /><br />Bien en el caso de PAT está más que claro que es soportada la instrucción, y únicamente mostrada si la habilitamos en el kernel.<br /><br />Acerca de cpuid, no sé como interactua con el kernel la verdad, desde luego el modulo lo tengo por defecto compilado... La utilidad cpuid también muestra que PAT está presente, aunque sobre NOPL no parece haber nada.<br /><br />Resumiendo, cpuinfo muestra lo que le da la gana al kernel mostrar, dmidecode muestra lo que le da la gana a la placa (bios) mostrar, y la utilidad cpuid pues mostrara todo si es que hace lo que dice y le pregunta al procesador, pero si resulta que le pregunta al procesador a través del kernel estaremos en las mismas (realmente le estaria preguntando al kernel.. y quien sabe éste como implementa la "pregunta").<br /><br />No he probado a meter un kernel no modificado y ejecutar cpuid para ver si muestra el flag PAT como disponible, supongo que me diria lo que ya sé, que dispongo de esa instruccion, o bien, no aparecería por tener un kernel que la deshabilita.<br /><br />Resumiendo tengo PAT, el cual si que mejora el rendimiento (ligeramente), y NOPL tal vez aunque sería una instrucción inutil para mi sistema.danitoolhttp://my.opera.com/danitoolnoreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-41995907192302530452011-11-16T16:43:57.190+01:002011-11-16T16:43:57.190+01:00Las flags que aparecen en /proc/cpuinfo son cualid...Las flags que aparecen en /proc/cpuinfo son <i>cualidades</i> del procesador e indican que <i>instrucciones especiales</i> posee, como por ejemplo una unidad de coma flotante (fpu), un juego de instrucciones de virtualización (vmx|svm) o el juego de instrucciones mtrr y pat. Es decir, si tu procesador tiene instrucciones para mtrr y pat, independientemente de que tengas o no compilado en el kernel soporte para mtrr y pat, dicha flags siempre estará presente. Aunque si no compilas el soporte para la flag X, no podrás sacar partido de ellas.<br /><br /><b>¿Cómo se genera la información contenida en /proc/cpuinfo?</b><br />El kernel, a través de CPUID (man cpuid), le pregunta al procesador que tipo de procesador es, familia, modelo, cache... y por supuesto pregunta que juegos de instrucciones posee. Toda esta información se almacena en /proc/cpuinfo y /sys/devices/system/cpu para que sea accesible facilmente. NOTA: Para que el kernel pueda preguntarle al procesador por sus características, debe compilarse el soporte para cpuid: <i> <*> /dev/cpu/*/cpuid - CPU information support </i>.<br /><br />El procesador devuelve un identificador de instrucción cpuid (<i>un número</i>). Y el kernel se encarga de traducir este número a una palabra legible por humanos; de tal forma que si el procesador devuelve 0*32+12 el kernel lo traduce como MTRR, 0*32+16 es traducido como PAT... NOTA: En /usr/src/linux/arch/x86/include/asm/cpufeature.h hay una lista con las <i>traducciones</i> del código cpuid devuelto por el procesador.<br /><br />Resumiendo, el kernel pregunta al procesador por los flags de los que dispone (cpuid), traduce el valor devuelto por la cpu a una palabra (cpufeature.h) y posteriormente coloca esta información en /proc/cpuinfo. No importa si no tienes compilado el soporte para <i>X flag</i>, si el procesador posee dicha flag aparecerá reflejado en /proc/cpuinfo. Aunque obviamente si no compilas el soporte para la <i>flag X</i> no podrás hacer uso de ella.<br /><br />Por otro lado dmidecode obtiene su información de la placa base, a quien pregunta por el hardware instalado. En situaciones normales la salida de <i>dmidecode -t processor</i> y <i>/proc/cpuinfo</i> deben ser idénticas; aunque pueden aparecer divergencias cuanto se hace overclock o si usas un kernel xen.Anonymoushttps://www.blogger.com/profile/09387646684121227737noreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-90998238694234638812011-11-15T21:48:20.083+01:002011-11-15T21:48:20.083+01:00Bien, empezaré diciendo que si no habilitas PAT, n...Bien, empezaré diciendo que si no habilitas PAT, no aparecerá en los flags /proc/cpuinfo. Solo cuando lo habilitas es cuando mostrará esa instrucción, así que..<br /><br />Lo mismo con NOPL, o cualquier otra instrucción, si el kernel no la habilita no aparece en cpuinfo...<br /><br />Quizás la forma correcta sería usando dmidecode. Como bien apuntas no parece que mi procesador tenga NOPL<br /><br />Pero desde luego sí que tiene PAT.<br /><br /><i>[root@tool dani]# dmidecode |grep PAT<br /> PAT (Page attribute table)<br />[root@tool dani]# dmidecode |grep NOPL<br />[root@tool dani]# </i>danitoolhttp://my.opera.com/danitoolnoreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-6554369143800644312011-11-15T19:30:00.629+01:002011-11-15T19:30:00.629+01:00Correcto, fallo mio, en /proc/mtrr no aparece nada...Correcto, fallo mio, en /proc/mtrr no aparece nada. Parece ser que, como tu mismo has indicado, el driver de nvidia lo hace todo solo, sin informar al kernel.<br /><br />En referencia al PAT, no se si será el caso pero miré en un viejo portátil, con un Pentium M, y no tenía soporte para PAT.<br /><i>root@notebook:/# cat /proc/cpuinfo <br />processor : 0<br />vendor_id : GenuineIntel<br />cpu family : 6<br />model : 13<br />model name : Intel(R) Pentium(R) M processor 1.73GHz<br />stepping : 8<br />cpu MHz : 800.000<br />cache size : 2048 KB<br />fdiv_bug : no<br />hlt_bug : no<br />f00f_bug : no<br />coma_bug : no<br />fpu : yes<br />fpu_exception : yes<br />cpuid level : 2<br />wp : yes<br /><b>flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2</b><br />bogomips : 1599.04<br />clflush size : 64<br />cache_alignment : 64<br />address sizes : 32 bits physical, 32 bits virtual<br />power management:</i><br /><br />Respecto a la instrucción NOPL, si tu procesador es de 32 bits, activar dicha opción no debería tener sentido; puesto que tu procesador no tendrá dicha instrucción. Verifica-lo en las <i>flags</i> que te arroja /proc/cpuinfo.Anonymoushttps://www.blogger.com/profile/09387646684121227737noreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-31437516268267920492011-11-14T23:35:35.796+01:002011-11-14T23:35:35.796+01:00Pues no, usando el driver de nvidia no se crean es...Pues no, usando el driver de nvidia no se crean esas regiones para la gráfica, al menos no aparecen en /proc/mtrr<br /><br />Comprobado en dos ordenadores con driver nvidia, en uno con una nvidia de última generación.<br /><i>cat /proc/mtrr <br />reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back<br />reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back<br />reg02: base=0x0c0000000 ( 3072MB), size= 128MB, count=1: write-back</i><br /><br />sin embargo las direcciones donde habría una de esas regiones no se corresponden con ninguna de la gráfica<br /><br /><i> Memory at fd000000 (32-bit, non-prefetchable) [size=16M]<br /> Memory at d0000000 (64-bit, prefetchable) [size=256M]<br /> Memory at ce000000 (64-bit, prefetchable) [size=32M]</i><br /><br />además de que sería una región tipo write-combining..<br /><br />Tal vez, y me da la sensación de que es así, los drivers de nvidia efectúan esa "reserva" de memoria pero a su forma y sin mostrarlo en la tabla /proc/mtrr.<br /><br />Sobre PAT, activado y ni un solo problema, compilando en el ordenador, con una carga al 100 por cien de memoria y de cpu. Incluso la suspensión y reanudación funcionan perfectamente. Simplemente pienso que como es imposible detectar que CPUs se ven afectadas exactamente por los posibles bugs lo han deshabilitado.<br /><br />Otra instrucción que también está deshabilitada aunque no tiene que ver con la gestión de memoria es NOPL, Deshabilitado en la arquitectura de 32 bits, solo disponible para 64 bits. Yo la he habilitado para probar, aunque me da que la instrucción no es usada por ningún software (creo que los compiladores también lo han deshabilitado para arquitecturas de 32 bits...)<br /><br />La verdad que estos temas son un poco oscuros, aunque interesantes.<br /><br />Saludosdanitoolhttp://my.opera.com/danitoolnoreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-79216894723751722032011-11-14T19:38:12.136+01:002011-11-14T19:38:12.136+01:00Si estas usando el driver de nvidia, ejecutar el c...Si estas usando el driver de nvidia, ejecutar el comando <i>echo "base=0xd0000000 size=0x10000000 type=write-combining" >| /proc/mtrr</i> no tiene ningún efecto puesto que el propio driver se encarga de crear dicha región mtrr.<br /><br />Puedes comprobar-lo reiniciando el PC y ejecutando <i>cat /proc/mtrr</i>, verás como ya existe dicha región sin necesidad de ejecutar ningún comando.<br /><br />Respecto a activar PAT, de acuerdo a los responsables del kernel no es buena idea hacerlo en tu micro; aunque obviamente si lo has probado y no te da problemas; perfecto.Anonymoushttps://www.blogger.com/profile/09387646684121227737noreply@blogger.comtag:blogger.com,1999:blog-507892079964167031.post-63488443943391128272011-11-12T14:14:29.261+01:002011-11-12T14:14:29.261+01:00Y que hay de crear manualmente las entradas MTRR?
...Y que hay de crear manualmente las entradas MTRR?<br /><br />Ejemplo, basándome en la información que devuelve lspci -v sobre la tarjeta gráfica<br /><br /><i>01:00.0 VGA compatible controller: nVidia Corporation NV31M [GeForce FX Go5650] (rev a1) (prog-if 00 [VGA controller])<br /> Subsystem: Dell Device 019c<br /> Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 248, IRQ 11<br /> Memory at fc000000 (32-bit, non-prefetchable) [size=16M]<br /> Memory at d0000000 (32-bit, prefetchable) [size=256M]<br /> [virtual] Expansion ROM at fd000000 [disabled] [size=128K]<br /> Capabilities: <br /> Kernel driver in use: nvidia<br /> Kernel modules: nvidia, nvidiafb, nouveau<br /><br /><br />echo "base=0xd0000000 size=0x10000000 type=write-combining" >| /proc/mtrr</i><br /><br />Aunque según la gente de Nvidia<br /><i> if you are using the NVIDIA Linux graphics driver, you do not need to manually configure MTRRs, the driver will take the steps necessary to ensure mappings of both system memory and GPU BARs have the correct memory types.</i><br /><br />Además, otra cosa interesante, PAT que es una instrucción de procesador íntimamente relacionada con MTRR, en los últmos kernels lo han deshabilitado en procesadores antiguos (el caso de mi Pentium M)<br /><br />arch/x86/kernel/cpu/intel.c :<br /><i><br /> /*<br /> * There is a known erratum on Pentium III and Core Solo<br /> * and Core Duo CPUs.<br /> * " Page with PAT set to WC while associated MTRR is UC<br /> * may consolidate to UC "<br /> * Because of this erratum, it is better to stick with<br /> * setting WC in MTRR rather than using PAT on these CPUs.<br /> *<br /> * Enable PAT WC only on P4, Core 2 or later CPUs.<br /> */<br /> if (c->x86 == 6 && c->x86_model < 8)<br /> clear_cpu_cap(c, X86_FEATURE_PAT);<br /></i><br /><br />Parece ser que por seguridad está deshabilitado por un posible fallo en algunos modelos. El pentium M es un modelo 9, por tanto he cambiado la linea x86_model < 8<br />para impedir que deshabilite PAT. El resultado es que compilando de nuevo el kernel, tengo esa instruccion habilitada, y parece que mejora ligeramente el funcionamiento del la tarjeta gráfica.<br /><br />Más informacion en profundidad sobre este tema seria interesante, a veces no sé si realmente cambiar estos parametros vale la penadanitoolhttp://my.opera.com/danitoolnoreply@blogger.com