[ DEBATE ] ¿Cómo optimizar kernel 3.0.8?

[ontogate]

Hola,

Este mensaje es principalmente para Kra1o5 que está haciendo un estupendo trabajo para nuestro G300. Pero el hilo está abierto a todos. No lo publico en Modaco porque los ingleses parecen muy poco abiertos a sugerencias "técnicas" si no eres un crack; además de por el tema del idioma.

Bueno, a lo que iba... ¿cómo se podría mejorar el kernel 3.0.8 del G300?

Antes de nada explicar por qué abro este hilo: Yo vengo de un ZTE Skate. Como sabéis tiene la misma RAM que el G300, pero es ARMv6 (el G300 es ARMv7). En principio nuestro terminal tendría que ser muy superior, pero lo cierto es que en muchas ocasiones echo de menos el Skate. Lo que más me preocupa es el tema de la memoria. En el G300 creo que es un aspecto que hay que mejorar mucho: la gestión es mejorable, pero también la cantidad que queda libre. Un ejemplo: hasta hace muy poco la RAM libre del G300 se quedaba en 384MB, con los últimos cambios de Dazz y Kra ya tenemos unos 400MB. Pero, ¿se puede conseguir más? El ZTE desde hace tiempo deja libres unos 415MB, ¿cómo es eso posible? Por una parte está el consumo de RAM de Android como SO que puede ser menor en ese terminal, pero por otra está el kernel. Evidentemente que si el hardware es diferente, los módulos necesarios también lo serán, y por tanto es posible que el Skate necesite meno código. Pero entonces yo me pregunto: ¿se podría optimizar aún más el kernel del G300?

Pues aquí es dónde toma sentido este hilo sobre... cómo optimizar aún más el kernel 3.0.8.

Aquí mi primera sugerencia: Tengo instalada la ROM CM10.1 del domingo 5 de mayo. Haciendo un simple "zcat /proc/config.gz" y mirando los sources de https://github.com/Kra1o5/android_kernel_huawei_u8815 llego a la conclusión de que tal vez se podrían limpiar algunas cosas. Por ejemplo, ¿por qué incluir la parte de CIFS (Samba) directamente en el kernel? ¿No sería mejor ponerla como un módulo? No digo quitarle el soporte (siempre es útil poder conectar con una unidad de red desde el móvil), ¿pero por qué no dejarlo como un módulo y cargarla sólo cuando se usa? No creo que muchos usuarios lo utilicen, por lo que podríamos rascar alguno KBs de memoria libre. Cuando se compila como módulo "cifs.ko" ocupa entre 300 y 400KB.

¿Qué sugiero entonces? Simple, cambiar:

CONFIG_CIFS=y

por

CONFIG_CIFS=m

En el archivo
android_kernel_huawei_u8815 / arch / arm / configs / cyanogen_u8815_defconfig

Con eso esa parte se compilará como un módulo y no estará integrada en el kernel; pero si hace falta utilizarlo se cargará en tiempo de ejecución y por tanto la funcionalidad seguirá estando y no se pierde nada.

¿Alguien quiere probar a compilar el kernel de esta forma?
¿Alguien tiene otras sugerencias para mejorar el kernel en nuestro teléfono?

[Kra1o5]

Porfin alguien que aporta ideas jeje.

Esto si es posible. Mi kernel puede optimizarse mas ya que se puede hacer mas "liviano" pero requiere mucho tiempo el ir linea por linea mirando si debe estar activado, desactivado o compilarse como modulo.

Un Saludo

[Alkalinorap]

Originalmente Escrito por ontogate

Hola,

Este mensaje es principalmente para Kra1o5 que está haciendo un estupendo trabajo para nuestro G300. Pero el hilo está abierto a todos. No lo publico en Modaco porque los ingleses parecen muy poco abiertos a sugerencias "técnicas" si no eres un crack; además de por el tema del idioma.

Bueno, a lo que iba... ¿cómo se podría mejorar el kernel 3.0.8 del G300?

Antes de nada explicar por qué abro este hilo: Yo vengo de un ZTE Skate. Como sabéis tiene la misma RAM que el G300, pero es ARMv6 (el G300 es ARMv7). En principio nuestro terminal tendría que ser muy superior, pero lo cierto es que en muchas ocasiones echo de menos el Skate. Lo que más me preocupa es el tema de la memoria. En el G300 creo que es un aspecto que hay que mejorar mucho: la gestión es mejorable, pero también la cantidad que queda libre. Un ejemplo: hasta hace muy poco la RAM libre del G300 se quedaba en 384MB, con los últimos cambios de Dazz y Kra ya tenemos unos 400MB. Pero, ¿se puede conseguir más? El ZTE desde hace tiempo deja libres unos 415MB, ¿cómo es eso posible? Por una parte está el consumo de RAM de Android como SO que puede ser menor en ese terminal, pero por otra está el kernel. Evidentemente que si el hardware es diferente, los módulos necesarios también lo serán, y por tanto es posible que el Skate necesite meno código. Pero entonces yo me pregunto: ¿se podría optimizar aún más el kernel del G300?

Pues aquí es dónde toma sentido este hilo sobre... cómo optimizar aún más el kernel 3.0.8.

Aquí mi primera sugerencia: Tengo instalada la ROM CM10.1 del domingo 5 de mayo. Haciendo un simple "zcat /proc/config.gz" y mirando los sources de https://github.com/Kra1o5/android_kernel_huawei_u8815 llego a la conclusión de que tal vez se podrían limpiar algunas cosas. Por ejemplo, ¿por qué incluir la parte de CIFS (Samba) directamente en el kernel? ¿No sería mejor ponerla como un módulo? No digo quitarle el soporte (siempre es útil poder conectar con una unidad de red desde el móvil), ¿pero por qué no dejarlo como un módulo y cargarla sólo cuando se usa? No creo que muchos usuarios lo utilicen, por lo que podríamos rascar alguno KBs de memoria libre. Cuando se compila como módulo "cifs.ko" ocupa entre 300 y 400KB.

¿Qué sugiero entonces? Simple, cambiar:

CONFIG_CIFS=y

por

CONFIG_CIFS=m

En el archivo
android_kernel_huawei_u8815 / arch / arm / configs / cyanogen_u8815_defconfig

Con eso esa parte se compilará como un módulo y no estará integrada en el kernel; pero si hace falta utilizarlo se cargará en tiempo de ejecución y por tanto la funcionalidad seguirá estando y no se pierde nada.

¿Alguien quiere probar a compilar el kernel de esta forma?
¿Alguien tiene otras sugerencias para mejorar el kernel en nuestro teléfono?

Sencillamente brutal.

[ontogate]

Hola,

Pues nada, me alegro que os parezca bien. Yo ya me he mirado el config línea a línea, y lo primero que he visto (por mi experiencia con el tema) es esto. Así que si Kra quiere ya puede probarlo.

Aún así, miraré el config del ZTE Skate para ver si puedo encontrar alguna cosa más. También pienso en si no se podrían poner los filesystems ext2 y ext3 como módulos, porque por defecto la ROM bootea con todo en EXT4, y por tanto no serían necesarios. Aún así, habría que hacer pruebas, no sea que alguna cosa falle en el boot.

Después de los módulos, habría que mirar si algo referido a la memoria se puede optimizar: liberar buffers innecesarios o pulir alguna cosa.

Desde luego pienso que lo primero para "optimizar" es meterse con el kernel, porque al fin y al cabo CM, AOKP, etc. ya lo están trabajando. En lo que nadie que no sea de la comunidad G300 está trabajando es el kernel. Hasta ahora el objetivo era que funcionara; ahora ya podemos ir a optimizar.

[ontogate]

Hola,

He estado un tiempo sin hacer nada con el desarrollo del G300. Y además, no he encontrado nada por el momento para optimizar el kernel. Pero vuelvo a la carga con otra sugerencia ahora sobre la memoria flash interna del teléfono.

Resulta que el particionamiento de nuestro móvil incluye un espacio que no estamos utilizando. Por supuesto, a más espacio mejor, pues se puede utilizar para más cosas. Me explico: las roms oficiales incluyen soporte para la partición "/cust". Esa partición es para que las operadoras pongan allí lo que quieran sin tocar la partición SYSTEM. Eso es una buena idea, porque resulta más sencillo para los desarrolladores distribuir nuevos firms sin tener que tocar muchas cosas. Por supuesto nosotros no necesitamos ese espacio, y esa parece la razón por la cual hace bastante tiempo que se eliminó de los fuentes de las roms cocinadas (tipo CM, PACMAN, etc.). Pero resulta, que eso no tiene sentido: la partición sigue estando ahí, pero simplemente no se monta. Es decir, que no ganamos nada de espacio, todo lo contrario, lo perdemos porque lo tenemos pero no lo usamos.

¿Para qué podríamos aprovechar ese espacio? Pues depende del uso que le queramos dar. Algunos ejemplos:

- Para poner allí la carpeta dalvik-cache y liberar algo de espacio en "/data" (eso implica montar la partición rw).
- Copiar en ella datos que no se modifiquen, como la ISO con los drivers del móvil (para eso se puede montar la partición ro).

Desde luego es algo simple y sin complicaciones, sólo hace falta que el kernel "recupere" este espacio. Y digo el kernel, porque el archivo que hace todo el trabajo es el "init.huawei.rc", que como sabéis está en la partición KERNEL del teléfono, y que no se puede modificar "realmente" si no se flashea un nuevo kernel.

Además hace tiempo que hasta los recoverys para nuestro teléfono incluyen soporte para esta partición extra. Simplemente hay que "recuperar" el soporte en el kernel, cosa por otro lado extremadamente sencilla. Aquí tenéis las modificaciones que habría que hacer en el archivo "/init.huawei.rc" del kernel (sólo publico los cambios necesarios, que son dos líneas):

on init
	mkdir /cust
	[...]

on fs
	[...]
	# Add this after all other mounts!
	mount ext4 /dev/block/mmcblk0p18 /cust ro barrier=1,nodelalloc
	[...]

Por supuesto, eso es para montar la partición como ReadOnly, que es más aconsejable, pues si luego se quiere hacer escribible basta con un remount, sin tocar nada del kernel.

Kra105, ¿te animas a parchear los sources oficiales y recuperar el soporte? Ya sé que eso se podría hacer en un script en el etc/init.d, pero es mejor hacer symlinks a esa partición que estar pendiente de scripts que puede ser que fallen. Total, las roms originales y los recoverys ya trabajan con esta partición. ¿Por qué eliminarla entonces?

[leillo1975]

Estas son las aportaciones que a mi me gustan, tocar los "intringulis" del Kernel y no simples modificaciones de personalización. Me recuerda a mi etapa de Gentoo desactivando opciones en las fuentes del Kernel de cosas que no sirven para nada o que no soporta el equipo.

La verdad es que molaría muchisimo disponer de unos cuantos megas más de RAM.

[ontogate]

Originalmente Escrito por ontogate

Kra105, ¿te animas a parchear los sources oficiales y recuperar el soporte? Ya sé que eso se podría hacer en un script en el etc/init.d, pero es mejor hacer symlinks a esa partición que estar pendiente de scripts que puede ser que fallen. Total, las roms originales y los recoverys ya trabajan con esta partición. ¿Por qué eliminarla entonces?

¿Nadie se anima a introducir estos cambios? Si tuviese acceso de escritura en el repositorio git lo haría yo mismo, pero mi trabajo no me deja mucho tiempo como para ser developer oficial.

[yoiyo]

como va esto?