{"id":183759,"date":"2026-10-12T16:53:43","date_gmt":"2026-10-12T14:53:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/linus-torvalds-eksperimentiruet-s-generacziej-izmenenij-k-yadru-cherez-ai"},"modified":"2026-10-12T16:53:48","modified_gmt":"2026-10-12T14:53:48","slug":"linus-torvalds-experiments-with-ai-generated-kernel-changes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/linus-torvalds-experiments-with-ai-generated-kernel-changes","title":{"rendered":"Linus Torvalds experimenta con la generaci\u00f3n de cambios en el n\u00facleo a trav\u00e9s de la IA","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds ha preparado un conjunto de parches para el subsistema de gesti\u00f3n de memoria en el n\u00facleo de Linux, implementando una optimizaci\u00f3n para la lectura de peque\u00f1os bloques de datos desde la cach\u00e9 de p\u00e1ginas sin cambiar at\u00f3micamente el contador de referencias (refcount) en la estructura folio. En el mensaje del commit se indica que los cambios, as\u00ed como las pruebas relacionadas, y el borrador de la nota fueron creados por el asistente AI Claude Code bajo la supervisi\u00f3n de Torvalds. El cambio se ha a\u00f1adido a una rama separada del n\u00facleo noref-filemap-read-with-llm y a\u00fan no est\u00e1 claro si se trasladar\u00e1 a la rama principal o si se trata simplemente de un experimento interno.<\/p>\n
Durante las pruebas, gracias a los parches, se logr\u00f3 aumentar el rendimiento de lectura de archivos peque\u00f1os en una configuraci\u00f3n con 8 hilos de 9.9-10.4 a 30-33 millones de operaciones por segundo (un aumento de 3 veces), con 4 hilos \u2014 de 8.9-11.6 a 25-26 millones\/s (un aumento de 2 veces), y con carga de un solo hilo de 7.9-8.1 a 8.8-8.9 millones\/s. Este aumento en el rendimiento se debe a que, al acceder simult\u00e1neamente a la cach\u00e9 de p\u00e1gina, hay una fuerte competencia entre los hilos por el acceso a la cach\u00e9. Por ejemplo, cuando 8 hilos intentan leer simult\u00e1neamente 16 bytes de datos, el 99.92% del tiempo se destina no a la lectura en s\u00ed, sino a la espera de acceso al contador de referencias.<\/p>\n
En el parche, para garantizar la correcci\u00f3n de los datos, en lugar de establecer bloqueos individuales, modificar contadores de referencias o realizar almacenamiento en b\u00fafer intermedio, se utiliza un enfoque alternativo que emplea la liberaci\u00f3n de memoria diferida con sincronizaci\u00f3n mediante el mecanismo RCU (Read-Copy-Update). El m\u00e9todo propuesto en el parche garantiza que la p\u00e1gina de memoria no se liberar\u00e1 f\u00edsicamente hasta que el hilo lector haya completado la copia de los datos. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"