Articuli praeparatio ad cursum alumni "Administrator Linux".

Antea locutus sum quomodo temptare ac efficere Hugepages in Linux.
Articulus hic tantum erit utilis si locum actualiter Hugepage utendi habebis. Multum mihi occurrit qui ex expectatione falluntur quod Hugepages magice fructibus meliorem emendare vult. Attamen ingenspaging locus multiplex est et effectus inhoneste uti potest degradare.

Pars I: Verificare quod Hugepages valeant Linux (originale hic)

problema:
Opus est ut reprimas si HugePages in tuo systemate valeant.

solution:
Suus 'pulchellus simplex:

cat /sys/kernel/mm/transparent_hugepage/enabled

Habebis aliquid simile hoc;

always [madvise] never

Videbis summam optiones available (semper, madvise, nunquam) , et optio actuosa currently parenthesi inclusa erit (per default madvise).

madvise significat quod transparent hugepages enabled solum ad memoriam areas quae explicite peto hugepages utens madvise(2).

semper significat quod transparent hugepages semper para omnibus processibus. Hoc plerumque melioris effectus est, sed si usum habes ubi plures processus parvam quantitatem memoriae consumunt, altiore memoria onus dramatically augere potest.

numquam significat quod transparent hugepages non continebitur etiam cum usura madvise petitum. Si vis invenire plura, contactus documentum Linux nuclei.

Quam mutare default valorem

optio 1: Directe mutare sysfs (Post reboot modulus ad valorem default ejus revertetur):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

optio 2: Default systema mutando nucleum cum modificata configuratione componendo (haec optio tantum commendatur si nucleo consuetudo es);

Ad defaltam semper pone, utere:

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

Ut pro defalta pone madvise, utere:

CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

Pars II: Commoda et Incommoda HugePages

Conabimur selective explanare commoda, incommoda et possibilia foveis utendi Hugepages. Cum articulus technologice complexus et pedanticus verisimile sit difficile intellectu pro hominibus qui Hugepages in cogitatione panacea sunt decepti, accurate pro simplici immolabo. Suus 'iustus prae oculis habitis multum argumenta sunt realiter complexa et ideo valde simpliciores.

Quaeso note nos loquimur de systematibus Linux 64-bit x86, et me simpliciter suppono systema vastarum perlucidarum subsidiorum (quia incommodum non est quod immanes paginas overscripte non sunt), sicut accidit in omnibus fere hodiernis Linux. ambitus.

Plura technicae descriptionis adiungam in nexus infra.

Rectum memoriam

Si programmator es C++, scis res in memoria habere inscriptiones specificas (valores monstratores).

Sed hae inscriptiones physicae inscriptiones in memoria non necessario reflectunt (RAM inscriptiones). inscriptiones in virtualis memoria repraesentant. Processus specialem MMU habet (administratio memoriae unitatis) moduli qui adiuvat tabulam nuclei virtualem memoriam ad locum physicum.

Accessus multae commoda, sed maximae sunt;

Euismod (pro variis de causis);
Programma solitudo, id est nulla programmatis memoria alterius programmatis legere potest.

Quae sunt paginae?

Virtus memoria in paginas dividitur. Quaeque singulae paginae ad certam physicam memoriam demonstrat, in RAM aream demonstrare potest, vel inscriptioni physicae notae assignata, ut video card.

Plurimae paginae vel RAM tractas vel involutae sunt, significationem in duris coegi vel SSD conditae sunt. nucleus corporis cuiuslibet paginae extensionem administrat. Si pagina spoofed accessitur, nucleus stamina sistit quod memoria accedere conatur, paginam a ferreo coegi/SSD in RAM legit, et deinde filum exsequens pergit.

Hic processus amnis perlucidus est, id quod non necessario legit immediate ab HDD/SSD. Magnitudo paginarum normalium 4096 bytes est. Hugepages amplitudo 2 megabytarum est.

Translation-associativum quiddam (TLB)

Cum programma accesserit ad paginam memoriae, CPU scire debet quamnam paginam physicam notitias ex lege datas (id est tabulam electronicam virtualem habere).

Kernel habet structuram datam (mensa pagina) in qua omnes informationes de paginis adhibentur. Hac data structura utens, describi potes inscriptionem virtualem ad electronicam physicam.

Tabula paginae tamen est satis multiplex et tarda, ideo simpliciter non possumus totam structuram notitiarum resolvere omni tempore processus memoriae accessuum.

Fortunate processus noster TLB habet quod destinatio sistit inter inscriptiones virtuales et physicas. Hoc significat, licet in primo conatu accessus paginae dividere debeamus, omnes accessus sequentes ad paginam in TLB tractari possunt, operandi celeritati permittentes.

Quia ut corporis fabrica perficiatur (quod primo loco tenet) eius capacitas limitatur. Si ergo plures paginas accedere voles, TLB mappings omnibus illis condere non poterit, ut propositum tuum multo tardius currat.

Hugepages venit ad liberandum

Quid ergo facere possumus vitare TLB redundantiam? (Propositum etiamnum tantundem memoriae assumimus).

Haec ubi Hugepages venit. Instead of 4096 bytes exigunt unum TLB ingressum, unum TLB ingressum nunc demonstrare potest ad 2 megabytes whopping. Sumamus TLB has 512 entries, hic sine Hugepages nos inserere possumus:

4096 b⋅512=2 MB

Quomodo ergo cum illis comparamur?

2 MB⋅512=1 GB

Inde est quod Hugepages terribilis est. Fructificationem sine magno labore emendare possunt. Sed cautiones hic significantes sunt.

Hugepages spoofing

Automatice monitores nucleus quotiens singula pagina memoriae adhibetur. Si parum corporis memoria (RAM), nucleus minus momenti (minus saepe usus est) movebit paginas ad orbem rigidum ut aliquas RAM pro maioribus paginis liberet.
In principio, idem valet de Hugepag. Sed acinum nuclei nonnisi paginas integras, non singulas bytes, permutare potest.

Dicamus nos sic programma habere:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]);

Hoc in casu, nucleus necesse erit reponere (lego) quantum 2 megabytarum notitiarum e ferreo coegi/SSD modo tibi unum byte legere. Quod ad paginas regulares, solum 4096 bytes legendae sunt ex dura coegi/SSD.

Si igitur ingentis paginae opprimitur, tantum citius ad legendum est si totam paginam accedere debes. Hoc significat quod si diversis memoriae partibus passim accedere conaris et tantum duos kilobytes legere, regularibus paginis utere debes et nihil aliud solliciti.

Contra, si magnae memoriae successivis portio accedere debes, ingentes paginas tuas operas emendabunt. Tamen, debes ipsum probare (non cum programmate abstracto) et vide quid citius operatur.

Destinatio in memoria

Si scribis C, scias te ex cumulo utendo pondera memoriae postulare ad libitum. malloc(). Dicamus opus 30 memoriae bytes;

char* mymemory = malloc(30);

Ad programmatorem apparet, te "petere" 30 bytes memoriae ab operante systema et monstratorem ad aliquam virtualem memoriam reducere. Sed ipsum malloc () est a C munus quod vocat ab intra munus brk et sbrk petentibus vel liberam memoriam ab operating ratio.

Sed magis ac magis petens inhabilis ad singulas destinationes memoriam; Verisimile est aliquam portionem memoriam iam liberatam esse (free())ac reuse possumus. malloc() instrumentorum algorithmorum satis complexorum ad reusing memoriam liberatam.

Simul, omnia tibi latent, cur te curem? Sed quia provocatio free() non vult esse memoria necessario statim ad systema operantem rediit.

Talis est rei ac memoria ruptio. Maxime in casu segmentorum acervi sunt ubi pauci bytes adhibentur, dum omnia intermedia liberata sunt (free()).

Nota quaeso quod memoria ruptionis est topica incredibilis complexa, et etiam minor mutatio progressionis significantem ictum habere potest. Pleraque programmata memoriam ruptionis notabilium non facient, sed scire debes, si in aliqua parte acervi disrumpens est quaestio, immanes condicionem deteriorem facere possunt.

Usus selectivam hugepages

Articulum perlectis decrevistis quae progressionis tuae partes usui ingentibus paginis prodesse possunt et quae non possunt. Itane ingentiae paginae efficiantur omnino?

Feliciter uti potes madvise()ut in illis tantum locis memoriae, ubi utile esset.

Primum, reprehendo quod ingentes paginas in madvise () modum utendi currit instructiones in principio articuli.

deinde utere madvise()nucleum prorsus indica, ubi vastpages utantur.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

Nota quod hic modus est simpliciter consilium ad nucleum quomodo ad memoriam administrandam. Hoc non significat quod nucleus ingentis paginas pro data memoria sponte utetur.

Refer ad documenta (manpage) madvisediscere de memoria et administratione madvise()hic locus incredibiliter ardua eruditione caret. Si ergo vis vere bonum illud obtinere, praepara te legere et probare paucis septimanis antequam aliquos eventus positivos expectes.

Quid legere?

Habesne quaestionem? Commentaria in scribe!

Source: www.habr.com

Commoda et Incommoda HugePages