Salutare, Tiberiu, On Thu, 2016-04-07 at 17:46 +0000, Tiberiu IORGULESCU (25243) via so wrote: > Am o intrebare: > Cum se prinde sistemul de operare daca sa dea sau nu sigsegv (sau ce > se intampla de fapt in spate atunci cand se aloca o pagina?). > > De exemplu, daca eu aloc o zona de memorie, ea nu se afla nici in > memoria fizica (datorita "demand paging"), nici in memoria secundara, > deci in tabela de pagini presupun ca flag-ul de validitate ar trebui > sa fie invalid. Si atunci de unde stie daca a fost alocata de mine? > Sau care e diferenta intre asta si cazul in care pur si simplu incerc > sa scriu la o adresa oarecare din spatiul meu virtual, fara sa fi > alocat nimic acolo?
Secretul care îți răspunde la întrebarea ta vine de la faptul că pe Linux apelul de sistem 'mmap' nu creează pe loc, imediat, maparea între pagina virtuală și pagina fizică, ci doar creează o intrare/informație în gestiunea internă kernelului pentru memoria virtuală asociată procesului care apelează 'mmap'. Astfel, primul acces ulterior la acea pagină va avea același efect ca în cazul accesului la o pagină care nu îi aparține procesului pentru că nu există încă maparea în tabelul de pagini. Puțin background: De fiecare dată când un proces accesează memorie care nu îi aparține (a se citi "pentru care nu are o intrare în tabela de pagini"), __hardware-ul__ va semnala eroarea generând o întrerupere (cunoscută ca 'trap') care va fi tratată de kernel. Deci, și în cazul în care accesul s-a făcut pentru o pagină alocată cu 'mmap' (vorbim de primul acces la o astfel de pagină), hardware-ul va genera trap-ul. Trap-ul, repet, este tratat de kernel. Acum, kernel-ul trebuie să decidă: a) Este cumva o pagină alocată cu 'mmap', dar accesată prima dată? Atunci creează maparea efectivă (noua intrare în tabela de pagini a procesului) și îi dă controlul înapoi procesului. Asta se mai cheamă "minor page fault" (vezi laboratorul 6 [1]). b) Este o pagină care nu îi aparține procesului? Atunci îi va trimite acestuia SIGSEGV. Am simplificat mult aici arborele de decizie al kernelului în cazul unui page-fault. Mai multe informații găsești în "Understanding the Linux Kernel", ediția 3, [2], o carte care intră în bibliografia cursului Sisteme de Operare 2, anul IV. Ai acolo: - secțiunea '16.2.2. Creating a Memory Mapping', p791, îți descrie în detaliu ce face 'mmap'; secțiunea '16.2.4. Demand Paging for Memory Mapping', p793, subliniază faptul că maparea nu se face în momentul apelului 'mmap', ci ulterior - secțiunea '9.4. Page Fault Exception Handler', p457, prezintă în detaliu arborele de decizie și pașii urmați de kernel în tratarea unui 'page fault' Observații: Asta este politica Linux-ului. Ar fi putut crea la apelul 'mmap' mapările necesare și astfel nu s-ar fi mai generat page fault-uri la primele accesări ale paginilor alocate. Însă abordarea Linux-ului are avantajul că păstrează memoria cât mai puțin ocupată: va aloca pagini 'on demand', doar atunci când procesul o va cere prin accesare (citire/scriere/execuție). Dezavantajul evident este tot acest overhead, deciziile pe care trebuie să le ia kernel-ul și parcurgerea aceluiași arbore de decizie ca în cazul unui acces invalid normal. Se consideră totuși că page fault-urile sunt evenimente rare și în consecință nu costă foarte mult sistemul. [1] http://ocw.cs.pub.ro/courses/so/laboratoare/laborator-06#exercitiul_6_-_page_fault-uri_05p [2] https://elf.cs.pub.ro/so2/res/doc/lin-kernel/O%27Reilly%20-% 20Understanding%20The%20Linux%20Kernel%20-%203rd%20Edition.pdf Costin _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
