[{"data":1,"prerenderedAt":27},["ShallowReactive",2],{"note-how-a-plugins-memory-is-judged-ca":3},{"slug":4,"order":5,"title":6,"summary":7,"measured":8,"topic":9,"toc":10,"html":26},"how-a-plugins-memory-is-judged",10,"Com es jutja la memòria d'un plugin","La memòria d'un plugin es mesura per instància, es vigila si creix, es limita amb un límit dur i es jutja contra el pressupost de cada amfitrió, perquè cap plugin no es qualifiqui de bo en un amfitrió al qual faria mal.","plugin-qualify, octubre del 2026. Els pressupostos de la Raspberry Pi són provisionals fins que es llegeixin en una Pi.","qualify",[11,14,17,20,23],{"id":12,"title":13},"petjada-per-instancia","Petjada per instància",{"id":15,"title":16},"creixement-en-el-temps","Creixement en el temps",{"id":18,"title":19},"un-limit-dur","Un límit dur",{"id":21,"title":22},"un-veredicte-per-perfil-d-amfitrio","Un veredicte per perfil d'amfitrió",{"id":24,"title":25},"el-que-encara-no-es-mesura","El que encara no es mesura","\u003Cp>La memòria d'un plugin es jutja, no només s'enregistra: un plugin no s'ha de qualificar de bo en un amfitrió al\nqual faria mal i una Raspberry Pi també ho és. Ho fan quatre peces: una petjada per instància, una comprovació del\ncreixement en el temps, un límit dur i un veredicte per perfil d'amfitrió.\u003C\u002Fp>\n\u003Ch2 id=\"petjada-per-instancia\">Petjada per instància\u003C\u002Fh2>\n\u003Cp>Al costat del cost de cada freqüència, el registre diu quant ha crescut la memòria resident, en KB: després\nd'instanciar, després d'activar, en repòs després de processar i, per a un instrument, amb notes premudes (al mateix\nnombre que el cost) i què hi ha afegit una segona instància.\u003C\u002Fp>\n\u003Cp>La petjada de cada freqüència la pren un procés fill creat abans que existeixi cap instància, de manera que cap\ninstància anterior no ha fet créixer el procés i un plugin que hi mor només fa perdre la xifra d'aquella freqüència.\nEn CLAP, el que ha costat carregar el \u003Ccode>.clap\u003C\u002Fcode> se suma a la primera instància; un plugin LV2 es carrega amb la primera\ninstanciació. Una xifra que no s'ha pres no hi és, mai no val 0 i el registre en diu el motiu.\u003C\u002Fp>\n\u003Cp>En surten dues xifres, escrites al costat de les brutes perquè un client sumi els mateixos nombres que ha llegit el\nveredicte:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>firstInstanceKb\u003C\u002Fcode>: el màxim que ha ocupat una instància en qualsevol pas, amb tot el que comparteixen les seves\ninstàncies.\u003C\u002Fli>\n\u003Cli>\u003Ccode>perInstanceKb\u003C\u002Fcode>: el que costa una instància més: la part pròpia de la segona instància, més les veus (notes premudes\nmenys repòs). Sense una segona instància mesurada no hi ha res que separi el que es comparteix i és tota la primera.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>La segona instància es mesura fins al final dels seus primers blocs, no només fins a instanciar-la: altrament, un\nplugin que reserva memòria en activar-se semblaria gratuït.\u003C\u002Fp>\n\u003Cp>El fill no hereta el bloqueig de memòria de la sonda. Una petjada llegida amb el bloqueig comptaria cada pàgina que el\nplugin ha mapat, no les que ha tocat.\u003C\u002Fp>\n\u003Ch2 id=\"creixement-en-el-temps\">Creixement en el temps\u003C\u002Fh2>\n\u003Cp>Una freqüència la memòria de la qual continua pujant per sobre d'un sostre no supera la prova de durada, amb el motiu\n\u003Ccode>leaks\u003C\u002Fcode>. La sonda llegeix la memòria resident després d'un escalfament i un altre cop a mig camí fins al final; el\ncreixement es calcula de la lectura del mig a la més alta, per minut d'àudio. Mesurar només la segona meitat és el que\ndistingeix una biblioteca que ha acabat de carregar tard d'una fuita.\u003C\u002Fp>\n\u003Cp>El sostre és de 10 MB per minut. És provisional, s'ajusta a partir de mesures i el motiu del veredicte diu\n\u003Ccode>provisional\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2 id=\"un-limit-dur\">Un límit dur\u003C\u002Fh2>\n\u003Cp>Dos límits, cadascun amb la seva feina:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>plugin-hostd aplica \u003Ccode>memory.max\u003C\u002Fcode>\u003C\u002Fstrong> (cgroup v2) al fill de la sonda que supervisa. El nucli compta el que el plugin\nocupa de debò i en mata l'arbre al límit; el resultat és \u003Ccode>probe.memory-limit\u003C\u002Fcode>, llegit de \u003Ccode>memory.events\u003C\u002Fcode>. Una màquina\nsense el controlador delegat recorre a \u003Ccode>RLIMIT_DATA\u003C\u002Fcode> i ho diu al registre.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>plugin-qualify aplica \u003Ccode>RLIMIT_AS\u003C\u002Fcode>\u003C\u002Fstrong> als processos que engega ell mateix. Val tota la memòria de la màquina: la fita\nllunyana d'una execució més que no pas el seu pressupost, perquè l'espai d'adreces és el que un plugin reserva, no\nel que toca. No s'aplica en una compilació amb sanititzadors, que reserva molt més del que fa servir. La primera\nreserva refusada acaba el fill amb el resultat \u003Ccode>memory-limit-exceeded\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>En tots dos casos la cel·la porta el seu resultat i el límit, el registre s'escriu i les altres cel·les es jutgen. Un\namfitrió la cel·la del qual ha tocat el límit hi és \u003Ccode>unknown\u003C\u002Fcode>, en la dimensió de memòria.\u003C\u002Fp>\n\u003Ch2 id=\"un-veredicte-per-perfil-d-amfitrio\">Un veredicte per perfil d'amfitrió\u003C\u002Fh2>\n\u003Cp>El pressupost d'un perfil d'amfitrió té una part per instància i una xifra per a tota la consola. Un perfil sense\npressupost no hi llegeix res, que no vol dir un pressupost de 0: \u003Ccode>jalv\u003C\u002Fcode>, \u003Ccode>mod-host\u003C\u002Fcode> i \u003Ccode>omx-clap-host\u003C\u002Fcode> són amfitrions\ngenerals que no corresponen a cap màquina concreta. La memòria és una dimensió del veredicte amb els seus propis codis\n(\u003Ccode>hosting.memory.*\u003C\u002Fcode>) i pot decidir tota sola.\u003C\u002Fp>\n\u003Cp>\u003Ccode>perInstanceKb\u003C\u002Fcode> es llegeix contra la part d'una instància i \u003Ccode>firstInstanceKb\u003C\u002Fcode> contra la de tota la consola, de manera que\nun mostrejador amb una biblioteca compartida gran pot cabre una vegada en un amfitrió petit i es llegeix bé per a dues.\nPer cel·la, mana la pitjor situació:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>què s'ha llegit\u003C\u002Fth>\n\u003Cth>qualificació\u003C\u002Fth>\n\u003Cth>codi\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>una xifra per sobre d'un sostre\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>unsuitable\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>hosting.memory.above-ceiling\u003C\u002Fcode> (amb \u003Ccode>provisional\u003C\u002Fcode> quan el sostre ho és)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>cap xifra o un motiu al costat de les xifres\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>unknown\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>hosting.memory.unmeasured\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>dins d'un pressupost mesurat\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>suitable\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>hosting.memory.within-ceiling\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>dins d'un pressupost provisional\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>conditional\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>hosting.memory.within-provisional-ceiling\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Un plugin dins d'un pressupost provisional, doncs, no hi queda qualificat: es diuen la xifra i el sostre i el\nveredicte no diu que el plugin hi cap. Només ho fa un pressupost mesurat.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>El perfil de consola\u003C\u002Fstrong> és per a una màquina de 30 GiB: 16 GiB per als plugins d'una consola, la resta per al motor i\nel sistema i 4 GiB per a una instància, que és també la fita amb què la sonda limita una execució.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Una Raspberry Pi\u003C\u002Fstrong>: els perfils de 4 GB i 8 GB tenen la forma d'\u003Ccode>omx-clap-host\u003C\u002Fcode>, que és el que fa córrer un plugin en\nuna Pi. Les seves cel·les són les que Zynthian configura en una Pi: 48000 Hz i 128 mostres en una Pi 5 amb el kit V5, 256\nmostres en una Pi 4 i els altres kits. Els escombratges més amplis (de 44,1 a 192 kHz, de 128 a 1024 mostres) són cel·les\nde banc de proves per comparar amfitrions i cap plugin no s'hi jutja. El pressupost és tota la memòria de la placa\nmenys 1 GiB per al sistema i la interfície de Zynthian i la part d'una instància n'és una vuitena: 3 GiB i 384 MiB en 4\nGB, 7 GiB i 896 MiB en 8 GB. Són provisionals fins que es llegeixin en una Pi.\u003C\u002Fp>\n\u003Cp>Com que una xifra que falta es llegeix \u003Ccode>unknown\u003C\u002Fcode>, una consola que s'actualitza llegeix tots els plugins com a\n\u003Ccode>unknown\u003C\u002Fcode> fins que s'han tornat a mesurar. És la regla en acció: res no diu que les xifres antigues encara hi càpiguen.\u003C\u002Fp>\n\u003Ch2 id=\"el-que-encara-no-es-mesura\">El que encara no es mesura\u003C\u002Fh2>\n\u003Cp>El creixement en el temps d'un plugin CLAP: la sonda CLAP encara no fa una renderització contínua, de manera que\n\u003Ccode>leaks\u003C\u002Fcode> només s'aplica als plugins LV2 i un plugin CLAP es llegeix \u003Ccode>unsoaked\u003C\u002Fcode>. La petjada es mesura en tots dos\nformats.\u003C\u002Fp>\n",1793954996350]