Hur gör operativsystem för att övervaka minnesaccess?

[Mr Andersson]

Ni pratar om olika saker. Fragmentering på OS-nivå vs applikationsnivå.

Det är en kostnadsfråga. Ett OS skulle teoretiskt kunna hålla fysiskt minne permanent defragmenterat via MMUn, om man har oändligt med minne.
48 bitars adressrymd. 4kB pages för maximal flexibilitet. \(\frac{2^{48}}{2^{12}}=2^{36}\) antal pages.
Varje page tar 4 byte minne, så ca 274 GB minne går åt enbart till minneshantering. Per applikation. En normal dator har väl ca 50-100 program körandes samtidigt. Det går ganska fort överstyr.
Därför använder man vanligen större minnes-pages vilket gör att blocken som måste vara sammanhängande också blir större.

[sodjan]

Jag vet inte hur generellt begreppet "heap" är, det är inget jag känner igen i alla fall.
Så att tala om "heap" i ett generellt perspektiv blir begränsat till vissa OS. Sen så
är ju (väl?) heap (och stack) lokal per process, så det berör inte OS'ets generella
hantering av virtuellt minne direkt, på samma sätt som t.ex. vid allokering av minne
då en process skapas eller en image (exekverbar kod) laddas till en process, det
skiljer sig lite från t.ex en malloc() från en applikation.

Min erfarenhet kommer främst från VMS (vilket står för "Virtual Memory System).
Där finns "Nonpages Dynamic Memory" (som inte kan "pagas" ut från minnet) och
"Pages Dynamic Memory". Även "lock managern" har en egen minnessektion.
Dessa areor blir också fragmenterade (se "Number of Free Blocks" nedan), men
de växer också vid behov (allokeras från fritt minne av OS'et).

Kod: Markera allt

$ show memory /pool /full
              System Memory Resources on  2-APR-2019 10:20:56.44

Nonpaged Dynamic Memory      (Lists + Variable)
  Current Size (MB)                24.25   Current Size (Pagelets)     49664
  Initial Size (MB)                20.50   Initial Size (Pagelets)     41984
  Maximum Size (MB)               128.62   Maximum Size (Pagelets)    263424
  Free Space (MB)                  12.45   Space in Use (MB)           11.79
  Largest Var Block (MB)            1.58   Smallest Var Block (bytes)     64
  Number of Free Blocks            35875   Free Blocks LEQU 64 bytes       1
  Free Blocks on Lookasides        35813   Lookaside Space (MB)         8.26

(No Bus Addressable Memory allocated)

Paged Dynamic Memory         (Lists + Variable)
  Current Size (MB)                15.25   Current Size (Pagelets)     31248
  Free Space (MB)                  12.02   Space in Use (MB)            3.22
  Largest Var Block (MB)           11.96   Smallest Var Block (bytes)     16
  Number of Free Blocks              618   Free Blocks LEQU 64 bytes      81
  Free Blocks on Lookasides          616   Lookaside Space (KB)        63.46

Lock Manager Dynamic Memory
  Current Size (MB)                98.78   Current Size (Pages)        12645
  Free Space (MB)                  61.25   Hits                     30026112
  Space in Use (MB)                37.53   Misses                          0
  Number of Empty Pages             7797   Expansions                  12645
  Number of Free Packets          217956   Packet Size (bytes)             0
$

[bearing]

Det jag ville komma fram till var väl "essensen" av problemet med fragmentering. Byte ut "heap" mot "minne" och "matris" mot "process" för ett bättre exempel. Så min fråga var alltså om vissa OS eller vissa VM kan hantera detta. D.v.s ge en process ett (ur processens perspektiv) kontinuerligt block av 200 byte i den situationen?

[sodjan]

> 48 bitars adressrymd...

Det betyder så klart inte att man har motsvarande mängd fysiskt minne.
Alpha har 64 bit virtuellt minnesområde, men max 48 bit fysiska adress bitar.
Page storlek är 8K så med 4GB minne får man 512K st. "pages". Med 8 bytes
per entry i varje PTE (Page Table Entry) får man en "page table" om 4 MB.

Kod: Markera allt

$ show memory /physical
              System Memory Resources on  2-APR-2019 10:58:27.45

Physical Memory Usage (pages):     Total        Free      In Use    Modified
  Main Memory (4.00GB)            524288       29153      445840       49295

Of the physical pages in use, 12163 pages are permanently allocated to OpenVMS.
$

Sedan har andra strukturer i minnet en annan uppdelning så som i förra inlägget
enligt "Smallest Var Block (bytes)".

Dessa pages allokeras dynamiskt till nya processer eller processer som utökar minnet.
Det som triggar detta är en "Page Fault" (d.v.s att en process vill ha en page som
den inte har), vilket ger ett avbrott till OS'et för att sköta detta.

"Page Faults" är själva kärnan i minneshanteringen och det sker i princip konstant.

Kod: Markera allt

$ monitor /interval=1 page
                            OpenVMS Monitor Utility
                           PAGE MANAGEMENT STATISTICS
                                 on node xxxx
                             2-APR-2019 11:09:47.29

                                       CUR        AVE        MIN        MAX

    Page Fault Rate                   4.99      24.72       0.00     940.14
    Page Read Rate                    0.00       5.05       0.00     290.73
    Page Read I/O Rate                0.00       2.43       0.00     112.89
    Page Write Rate                   0.00       0.02       0.00       0.99
    Page Write I/O Rate               0.00       0.02       0.00       0.99

    Free List Fault Rate              1.99       1.17       0.00      57.94
    Modified List Fault Rate          1.99       2.13       0.00      85.92
    Demand Zero Fault Rate            0.00       3.10       0.00     153.85
    Global Valid Fault Rate           0.99      15.86       0.00     586.46
    Wrt In Progress Fault Rate        0.00       0.00       0.00       0.00
    System Fault Rate                 0.00       0.00       0.00       0.00

    Free List Size                27741.00   27718.03   27687.00   28322.00
    Modified List Size            49923.00   49961.18   49785.00   49998.00

> Så min fråga var alltså om vissa OS eller vissa VM kan hantera detta.

Ja, inom vissa gränser styrda av design och arkitektur, skulle jag säga.
I t.ex. VMS så utökas "Nonpaged Dynamic Memory" dynamiskt vi behov
(upp till en viss gräns).

EDIT: Poängen är väl kanske att det är svårt att tala om virtuell minnes
hantering i generella termer, det skiljer en del mellan hur olika OS har
implementerat det.

[Mr Andersson]

> Det betyder så klart inte att man har motsvarande mängd fysiskt minne.

Absolut, det är nog få som har det
Men program kan ju använda långt mycket mer virtuellt minne än vad det finns fysiskt minne. T.ex. spegling, delat minne, minnesmappade filer, etc.
Mitt exempel var ett värsta fall om man skulle använda "virtuell defragmentering" så kommer största lediga fysiska block minska allt eftersom program startas och stängs och tillslut måste man använda 4kB-pages överallt då även ledigt minne behöver utrymme för att markeras som ledigt.
Men mer realistiskt så om man har 1 GB sammanhängande ledigt minne använder man ju så klart 1st 1GB-page istället för 262144x 4kB.
(baserat på x86, andra familjer har andra gränser och storlekar)