Linux 6.9 oferirà una arrencada més ràpida en sistemes grans amb gran quantitat de RAM

Tux, la mascota del Kernel de Linux

El nucli de Linux és l'element principal dels sistemes operatius (SO) Linux, i és la interfície fonamental entre el maquinari d'un ordinador i els processos.

Fa pocs dies compartim aquí al bloc la notícia d'un dels canvis que podrem trobar al llançament del nucli de Linux 6.9, del qual actualment es troba en desenvolupament i ja s'han donat a conèixer diversos canvis i del que anunciem va ser que EXT2 ja passo a la categoria d'obsolet i també que es deixarà de banda l'ús de l'antic controlador NTFS a favor del controlador desenvolupat per Paragon Software.

Ara, en notícies més actuals sobre les novetats que ens presentés Linux 6.9, és que aquesta versió del Kernel comportarà una millora significativa en el temps d'inici per a usuaris que gestionen sistemes amb grans quantitats de RAM, especialment aquells que fan ús de pàgines HugeTLB. Això es tradueix en una reducció considerable en el temps que porta inicialitzar aquestes pàgines durant el procés darrencada del sistema.

Article relacionat:
Paragon llanço una implementació NTFS per el nucli de Linux

I és que el canvi afegit a Linux 6.9 permetrà que els sistemes amb una gran quantitat de pàgines HugeTLB experimentin una reducció notable al temps d'inici. Per exemple, en sistemes de 2 TB on s'inicialitzen 1800 pàgines d'1 GB, que actualment prenen entre 1 i 2 segons d'un total de 10 segons, el que sens dubte és una millora considerable en aquests temps. De manera similar, en hosts Intel de 12 TB on s'inicialitzen 11 pàgines d'776 GB, la qual cosa pot portar més d'un minut, s'observarà una reducció significativa en aquests temps d'inici.

Aquests avenços van ser possibles gràcies al treball dedicat del desenvolupador de Linux Gang Li de Bytedance, qui va implementar una sèrie de pegats que van passar per múltiples revisions per garantir una execució eficient. La infraestructura del nucli existent, com padata_do_multithreaded, va ser utilitzada amb modificacions mínimes per assolir aquests resultats.

Dues actualitzacions a v6…

– Es va corregir un error potencial a together_bootmem_prealloc_node
La implementació padata_do_multithreaded garanteix que cada
La tasca together_bootmem_prealloc_node gestiona un node. Tot i això, l'API descrita
al comentari padata_do_multithreaded indica que padata_do_multithreaded també
Podeu assignar diversos nodes a una tasca together_bootmem_prealloc_node.

Per evitar possibles errors de futurs canvis a padata_do_multithreaded,
S'introdueix together_bootmem_prealloc_parallel per embolicar el
together_bootmem_prealloc_node.

els beneficis d'aquestes millores són especialment notables en entorns on la disponibilitat del servei i el temps d'activitat del sistema són crítics, com en el cas d'hiperescaladors i grans organitzacions que manegen servidors molt grans. La reducció en el temps dinici durant reinicis és de gran benefici per garantir una operativitat més ràpida i eficient.

A més d'això, també val la pena esmentar un altre dels canvis que s'han inclòs a Linux 6.9 el qual és un pegat d'un experimentat enginyer de Linux a Intel, el qual introdueix en les actualitzacions de memòria cau x86 una tècnica millorada per limitar l'amplada de banda de la memòria, similar a la utilitzada per Intel a RDT i les CPU AMD EPYC amb el codi resctrl.

L'autor del pegat esmenta que:

El bucle de retroalimentació MBA_mbps augmenta la limitació quan un grup utilitza més ample de banda del que estableix l'usuari al fitxer d'esquema, i disminueix la limitació quan està per sota de l'objectiu.

Cal esmentar que la nova tècnica per limitar l'amplada de banda de la memòria està dissenyada per manejar de manera més eficient les càrregues de treball amb nivells de càrrega no uniformes, evitant penalitzacions innecessàries que passaven en versions anteriors del nucli.

Per evitar fluctuacions innecessàries en l'acceleració en cada iteració, l'indicador delta_comp s'utilitza per indicar els canvis reals a l'amplada de banda a registrar en la següent iteració a delta_bw. La limitació només es redueix si l'amplada de banda més delta_bw actual està per sota de l'objectiu de l'usuari.

Com a tal s'esmenta que l'algorisme funciona bé amb càrregues de treball d'amplada de banda constant, però podeu fallar si la càrrega de treball canvia just quan canvia la limitació. Per abordar això, es va implementar una tècnica més simple que calcula l'augment potencial de l'amplada de banda si es redueix la limitació al nivell superior següent, assegurant-se que segueixi estant per sota de l'objectiu de l'usuari abans de reduir la limitació.

si estàs interessat a poder conèixer més sobre això, pots consultar els detalls als següents enllaços: