[2000] Virtual Memory Management*

[Little Bear]

Ik heb altijd een vrij simpele voorstelling gehad van virtual memory. Virtual memory is ruimte op de harde schijf die behandeld wordt als ram geheugen. De data wordt wanneer nodig in het ram gepaged. Zo kan je dus 512 MB ram hebben en 1,5 GB virtual memory.

So far so good. Nu ben ik me er iets dieper in aan het verdiepen. Ik lees nu dat Win2k altijd 4 GB virtual memory reserveert. 2 GB voor kernel threads en 2 GB voor user mode threads. Ik citeer uit de MSCA boek: "The upper 2 GB is reserved for the system or for kernel-mode threads only. The lower portion of this upper 2 GB area is mapped directely by the hardware. Access to this lower portion is extremely fast."

Nu waar ik een beetje mee zit is het volgende. Het virtual memory is geheugen op de trage harde schijf. Hoe kan dit dan rechtstreeks via de hardware worden aangesproken en extreem snel zijn?

[ToFast]

Nu waar ik een beetje mee zit is het volgende. Het virtual memory is geheugen op de trage harde schijf. Hoe kan dit dan rechtstreeks via de hardware worden aangesproken en extreem snel zijn?

Dat kan niet, de enige manier om het te versnellen is te zorgen dat de juiste gegevens in het geheugen komt te staan en niet op de hd. Je zal dus meer geheugen erin moeten doen.

[maratropa]

Ik ben ook geen kei natuurlijk, maar ik weet wel dat het wat complexer licht dan "virtual memory", een pagefile is meer dan alleen dat (w9x had een swapfile, virtual memory, de NT pagefile is veel "cooler"). Bijvoorbeeld windows NT wel ruimte "reserveerd" in je pagefile, maar dat niet daadwerkelijk gebruikt, begrijpen sommigen niet en gillen dat windows NT altijd je pagefile gebruikt etc.

Misschien bedoelen ze de adressering in het geheugen ipv het daadwerkelijke gebruik, wat natuurlijk altijd langzemer is dan ram. Maarja nu begin ik weer te praten over dingen die me te boven gaan.

[ Voor 18% gewijzigd door maratropa op 12-07-2005 21:22 ]

[ToFast]

Nee je hebt geloof ik wel gelijk, er is standaard een page file in gebruik, die de meest voorkomende bestanden heeft gecached op een indexed page manier(denk ik)

Maar de enige manier om dat te voorkomen, en het sneller maken van de computer is dus meer geheugen. De page file kan dan kleiner gehouden worden, maar meestal wel +512mb omdat anders windows gaat zeuren of spelletjes(run out of virtual memory) terwijl je meer dan genoeg geheugen hebt laten we zeggen 2 gb. Maar ookal zet je dan 10gb virtual memory aan, met 2gb aan geheugen zal die dat niet vaak gebruiken, ookal heeft die wel 10gb in gebruik. Als je hem op 10mb zet, krijg je dus foutmeldingen, niet dat hij het echt gebruikt, maar wel controlleerd ofzo denk ik

[sjhgvr]

Als je 2 hd's in je pc hebt zitten, pleur de PF (Page-file) dan niet op de hd waar windows op staat, maar de andere.
Dat geeft ook weer wat performancewinst. (Tenzij dat een tragere hd is dan...)

[ Voor 6% gewijzigd door sjhgvr op 12-07-2005 21:31 ]

[Yofresh]

Het is niet extreem snel, want harde schijven zijn niet extreem snel. Geheugen is snel. Daardoor gooit men er ook 512 mb RAM bij in spelletjes ipv dat ze het virtueel memory eventjes 1 gb hoger zetten.

[Question Mark]

Weet je zeker dat je het hier niet hebt over systemen met 4 GB aan RAM geheugen? In het geval van dergelijke systemen wordt nl. het fysieke geheugen verdeeld in 2GB voor systemprocessen en 2 GB voor userprocessen (application space). Dit vanwege de 32 bits beperkingen van het OS.

Mochten in een systeem met 4 GB memory, bv. de systemprocessen niet genoeg hebben aan hun 2GB memory-space, dan kan het voorkomen dat een gedeelte gepaged gaat worden, terwijl het totale fysieke geheugen nog niet vol is (van de 2 GB userspace kan bv, nog 1 GB vrij zijn).

Via diverse opties in de boot.ini (/PAE) is deze verdeling aan te passen naar bv. 1 GB / 3 GB.

Zie oa: Intel Physical Addressing Extensions (PAE) in Windows 2000

Even with PAE enabled, the underlying architecture of the system is still based on 32-bit linear addresses. This effectively retains the 2 GB of application space and the 2 GB of kernel mode space because only 4 GB of addresses are available. However, multiple processes can immediately benefit from the increased RAM because they are less likely to encounter physical memory restrictions and begin paging. Additionally, applications can be modified to use the AWE API to allocate memory outside of the applications process space, bypassing the 2-GB limit for applications.

[ Voor 13% gewijzigd door Question Mark op 12-07-2005 21:41 ]

[maratropa]

DapinododiadeaL schreef op dinsdag 12 juli 2005 @ 21:31:
Als je 2 hd's in je pc hebt zitten, pleur de PF (Page-file) dan niet op de hd waar windows op staat, maar de andere.
Dat geeft ook weer wat performancewinst. (Tenzij dat een tragere hd is dan...)

In theorie klopt dat maar practisch is het tegenwoordig onzin, omdat er zo weinig gepaged word doordat er zo veel gehuegen in PC's tegenwoordig zit. Als je pagefile niet gebruikt wordt dan maakt het niet uit waar die staat, en wordt ie wel veel gebruikt dan heb je te weinig geheugen en moet je meer kopen. (en ik heb het hier even niet over servers). NT maakt ruimte aan in de pagefile voor alle programma's, voor ALS ze mogenlijk gepaged moeten worden als er geheugen gebrek is. Maar echt hard pagen gebeurt bij de meest mensen niet (weinig) meer. Laat je bijvoorbeeld een "window" lang openstaan, dan word deze weggepaged. Dus een goeie snelheids tip is je windows niet minimaliseren

[ Voor 3% gewijzigd door maratropa op 12-07-2005 21:39 ]

[downtime]

Question Mark schreef op dinsdag 12 juli 2005 @ 21:37:
Weet je zeker dat je het hier niet hebt over systemen met 4 GB aan RAM geheugen? In het geval van dergelijke systemen wordt nl. het fysieke geheugen verdeeld in 2GB voor systemprocessen en 2 GB voor userprocessen (application space). Dit vanwege de 32 bits beperkingen van het OS.

Mochten in een systeem met 4 GB memory, bv. de systemprocessen niet genoeg hebben aan hun 2GB memory-space, dan kan het voorkomen dat een gedeelte gepaged gaat worden, terwijl het totale fysieke geheugen nog niet vol is (van de 2 GB userspace kan bv, nog 1 GB vrij zijn).

Sterker nog, dat onderscheid tussen 2GB voor systeemprocessen en 2GB voor userprocessen bestaat ook wanneer je minder dan 4GB aan RAM hebt. Het is een denkbeeldige (dus virtuele) 4GB adresruimte die niet volledig gemapt hoeft te worden naar het aanwezige fysieke RAM en de paging file.

Misschien moet ik iets vollediger zijn: Virtueel geheugen slaat op de volledige geheugenruimte die een proces kan adresseren, ongeacht of dat fysiek een deel van het RAM is, of een deel van de pagefile, of zelfs niet-bestaand geheugen. De applicatie adresseert gewoon een stuk virtueel geheugen en het OS (en de MMU) regelen wel hoe dat stuk virtueel geheugen vertaald (gemapped) wordt naar fysiek geheugen.

[ Voor 18% gewijzigd door downtime op 12-07-2005 22:05 ]

[sanfranjake]

Ik zet nog even het OS waar het in de topicstart over gaat in de topictitel, dit per de Windows Operating Systems - Policy

[Little Bear]

Ik ga de post even vervolledigen en het hele hoofdstuk quoten:


Virtual Address Space

A Virtual address is the address space that an application uses to reference memory. When a process is launched in Windows 2000, VMM presents the process with 4 GB of virtual address space.

This 4 GB of virtual address space is divided as follows:

• The upper 2 GB is reserved for the system or for kernel-mode threads only. The lower portion of this upper 2 GB area is mapped directely by the hardware. Access to this lower portion is extremely fast.

• The lower 2 GB is available to both user-mode threads: for example, applications and kernel-mode threads. VMM can move it to disk if required. Windows 2000 divides the upper portion into a paged and nonpaged pool. Addresses in the paged pool can be swapped out to disk, but those in the nonpaged pool must remain in physical memory. The size of each page is 4 KB.

Hoe het er staat lijkt het er dus op dat er van 4 GB ram uitgegaan wordt. Dit staat echter nergens specifiek vermeld, en dan zou ook het hele principe van virtueel geheugen zijn doel missen lijkt me. Het is voor mij dus echt de vraag, hoe kan dit geheugen extreem snel zijn wanneer (als?) dit op een harde schijf staat.

En als het niet op een HD staat, dan zouden beide blokken toch even snel moeten zijn, en niet enkel het onderste deel van de eerste blok?

[elevator]

http://www.winntmag.com/A...IssueID=56&ArticleID=3686
en
http://www.winntmag.com/A...IssueID=58&ArticleID=3774

zijn artkelen die ik altijd erg helder vind

Je zou ook nog eens de artikelen van Raymond Chen kunnen doornemen: http://blogs.msdn.com/old...ve/2004/08/22/218527.aspx - misschien dat je dat wat meer informatie verschaft

Ook http://blogs.msdn.com/lar...ve/2005/03/25/402314.aspx kan je eens doornemen, ook http://blogs.msdn.com/lar...ive/2004/03/18/92010.aspx geeft nog wat meer informatie.

[Question Mark]

/downtime/ schreef op dinsdag 12 juli 2005 @ 21:45:
[...]
Sterker nog, dat onderscheid tussen 2GB voor systeemprocessen en 2GB voor userprocessen bestaat ook wanneer je minder dan 4GB aan RAM hebt. Het is een denkbeeldige (dus virtuele) 4GB adresruimte die niet volledig gemapt hoeft te worden naar het aanwezige fysieke RAM en de paging file.

Klopt, dit heb ik ondertussen ook gevonden. Elk proces krijgt 4 GB toegekend. Het memory management regelt via diverse translaties de exacte locatie van een virtueel adres naar een page frame.

Little Bear schreef op woensdag 13 juli 2005 @ 01:07:
En als het niet op een HD staat, dan zouden beide blokken toch even snel moeten zijn, en niet enkel het onderste deel van de eerste blok?

Nog even verder gezocht en het volgende gevonden: The Virtual-Memory Manager in Windows NT

Translation Lookaside Buffers (TLBs)
Considering all the work Windows NT does to retrieve the physical address of a page, addressing in general seems a little on the inefficient side. After all, to translate a single virtual address, the VMM must access memory in three physical pages of memory. However, Windows NT uses another addressing scheme in parallel with the virtual address translation technique described above.

Windows NT exploits the capability of modern CPUs by putting the translation lookaside buffer (TLB) to use. The TLB (often referred to as the internal or on-chip cache) is nothing more than a 64K buffer that is used by hardware to access the location of a physical address. Specifically, Windows NT uses the TLB to provide a direct connection between frequently used virtual addresses and their corresponding page frames. Using it, the VMM is able to go from a virtual address directly to the page frame, thereby avoiding translation through both the page directory and page table.

Because the TLB is a hardware component, its contents can be searched and compared completely in parallel with the standard address translation performed in software. So, the time saved in translating a virtual address comes without a tradeoff. Also, being a hardware mechanism, it is extremely fast in comparison to the software translation described earlier. A big win all the way around. Too bad there isn't room for more than 32 entries! Being a hardware component also has its limitations.

Als ik bovenstaand dus goed interpreteer wordt er gebruik gemaakt van een klein stuk hardware (TLB)binnen de I386 architectuur, waardoor niet elk virteel adres naar een page frame vertaald hoeft te worden. Dit zou kunnen slaan op de quote uit je studieboek.

offtopic:
Vragen hierover krijg je natuurlijk never-nooit-niet op een MCSA/MCSE examen

[ Voor 6% gewijzigd door Question Mark op 13-07-2005 10:06 ]