| Subject: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/13/2007 8:08:27 AM |
| From: Megan Kielman [Email Address Protection] |
If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode and 6GB to User-mode? Megan |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/14/2007 12:28:07 AM |
| From: "the_el_vez" [Email Address Protection] |
You will really want to get a copy of "Windows Internals". It covers all the basic concepts in Windows very well. In 32 bit windows you always have a 32 bit address space (4GB). With 2GB going to UM and 2GB to kernel. If you use the 3GB switch then you get 3GB of UM space if you link the app as "large address space aware". This squashes the kernel down to 1GB which is bad. The additional ram allows you to have more processes mapping memory to RAM. This is a very confusing area as there are lots of seemingly overlapped technologies (i.e AWE, PAE, 3GB, etc.). "Megan Kielman" <megan.kielman@gmail.com> wrote in message news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... > If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and > WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode > and 6GB to User-mode? > > Megan |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/14/2007 2:50:16 PM |
| From: "Ben Voigt [C++ MVP]" [Email Address Protection] |
"the_el_vez" <jonathanm@mindspring.com> wrote in message news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... > You will really want to get a copy of "Windows Internals". It covers all > the basic concepts in Windows very well. > > In 32 bit windows you always have a 32 bit address space (4GB). With 2GB > going to UM and 2GB to kernel. If you use the 3GB switch then you get 3GB > of Of course that is per-process, so you could use all 8GB of memory with 3-4 processes running. > UM space if you link the app as "large address space aware". This squashes > the kernel down to 1GB which is bad. The additional ram allows you to have > more processes mapping memory to RAM. This is a very confusing area as > there are lots of seemingly overlapped technologies (i.e AWE, PAE, 3GB, > etc.). > > > "Megan Kielman" <megan.kielman@gmail.com> wrote in message > news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >> and 6GB to User-mode? >> >> Megan > |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/15/2007 8:26:42 AM |
| From: Megan Kielman [Email Address Protection] |
Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and 6GB goes to UM? Ben Voigt [C++ MVP] wrote: > "the_el_vez" <jonathanm@mindspring.com> wrote in message > news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >> You will really want to get a copy of "Windows Internals". It covers all >> the basic concepts in Windows very well. >> >> In 32 bit windows you always have a 32 bit address space (4GB). With 2GB >> going to UM and 2GB to kernel. If you use the 3GB switch then you get 3GB >> of > > Of course that is per-process, so you could use all 8GB of memory with 3-4 > processes running. > >> UM space if you link the app as "large address space aware". This squashes >> the kernel down to 1GB which is bad. The additional ram allows you to have >> more processes mapping memory to RAM. This is a very confusing area as >> there are lots of seemingly overlapped technologies (i.e AWE, PAE, 3GB, >> etc.). >> >> >> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >>> and 6GB to User-mode? >>> >>> Megan > > |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/15/2007 8:47:36 AM |
| From: "SoftLion" [Email Address Protection] |
2GB kernel, 2GB UM, over memory is not used and wasted. With this 32 bit system you can map 4Gb max only, not 8. "Megan Kielman" <megan.kielman@gmail.com> a �crit dans le message de news: u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... > Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and 6GB > goes to UM? > > > > > Ben Voigt [C++ MVP] wrote: >> "the_el_vez" <jonathanm@mindspring.com> wrote in message >> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>> You will really want to get a copy of "Windows Internals". It covers all >>> the basic concepts in Windows very well. >>> >>> In 32 bit windows you always have a 32 bit address space (4GB). With 2GB >>> going to UM and 2GB to kernel. If you use the 3GB switch then you get >>> 3GB of >> >> Of course that is per-process, so you could use all 8GB of memory with >> 3-4 processes running. >> >>> UM space if you link the app as "large address space aware". This >>> squashes the kernel down to 1GB which is bad. The additional ram allows >>> you to have more processes mapping memory to RAM. This is a very >>> confusing area as there are lots of seemingly overlapped technologies >>> (i.e AWE, PAE, 3GB, etc.). >>> >>> >>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>>> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >>>> and 6GB to User-mode? >>>> >>>> Megan >> |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/15/2007 1:06:03 PM |
| From: "the_el_vez" [Email Address Protection] |
Sorry - let me be more clear. Each process has a 4GB virtual address space. The lower 2GB are UM and the upper 2GB are KM. Each process has this property. However, almost all of the KM space in each process is mapped to the same backing physical memory. Whereas almost all of the UM space of each process is mapped to its own backing pages. So for example - if you have 2 processes - and mapped all the UM and KM space to RAM - you might expect to use 8GB of RAM - 2*2GB for the 2 processes UM space and 2*2GB for each of the processes KM space. But in fact you would only use around 6GB of RAM as the kernel space is a shared mapping between the 2 processes (and processes for that matter). If you used the /3GB switch in this scenario then you would use around 7GB or RAM - 3GB for each process's UM space and 1GB for the shared kernel mapping. Note that the reason I say "mostly" and "almost all" is because there are some pages that are shared between all processes in UM (i.e. read-only code pages, etc.). Also - some kernel pages are private to a process as well (i.e. page tables, etc.) - but generally speaking you can think of KM space as wholly shared amongst all processes. Does this make more sense? "Megan Kielman" <megan.kielman@gmail.com> wrote in message news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... > Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and 6GB > goes to UM? > > > > > Ben Voigt [C++ MVP] wrote: >> "the_el_vez" <jonathanm@mindspring.com> wrote in message >> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>> You will really want to get a copy of "Windows Internals". It covers all >>> the basic concepts in Windows very well. >>> >>> In 32 bit windows you always have a 32 bit address space (4GB). With 2GB >>> going to UM and 2GB to kernel. If you use the 3GB switch then you get >>> 3GB of >> >> Of course that is per-process, so you could use all 8GB of memory with >> 3-4 processes running. >> >>> UM space if you link the app as "large address space aware". This >>> squashes the kernel down to 1GB which is bad. The additional ram allows >>> you to have more processes mapping memory to RAM. This is a very >>> confusing area as there are lots of seemingly overlapped technologies >>> (i.e AWE, PAE, 3GB, etc.). >>> >>> >>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>>> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >>>> and 6GB to User-mode? >>>> >>>> Megan >> |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/15/2007 2:53:45 PM |
| From: "Ben Voigt [C++ MVP]" [Email Address Protection] |
"SoftLion" <nospam@replyToGroup.com> wrote in message news:e4g0Z75JIHA.6008@TK2MSFTNGP05.phx.gbl... > 2GB kernel, 2GB UM, over memory is not used and wasted. > With this 32 bit system you can map 4Gb max only, not 8. Not true. Each process can only address up to 4GB of memory, but the other memory can be used by other processes. It is not wasted. > > > "Megan Kielman" <megan.kielman@gmail.com> a �crit dans le message de news: > u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and 6GB >> goes to UM? >> >> >> >> >> Ben Voigt [C++ MVP] wrote: >>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>> You will really want to get a copy of "Windows Internals". It covers >>>> all the basic concepts in Windows very well. >>>> >>>> In 32 bit windows you always have a 32 bit address space (4GB). With >>>> 2GB going to UM and 2GB to kernel. If you use the 3GB switch then you >>>> get 3GB of >>> >>> Of course that is per-process, so you could use all 8GB of memory with >>> 3-4 processes running. >>> >>>> UM space if you link the app as "large address space aware". This >>>> squashes the kernel down to 1GB which is bad. The additional ram allows >>>> you to have more processes mapping memory to RAM. This is a very >>>> confusing area as there are lots of seemingly overlapped technologies >>>> (i.e AWE, PAE, 3GB, etc.). >>>> >>>> >>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>>>> WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>> Kernel-mode and 6GB to User-mode? >>>>> >>>>> Megan >>> > |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/18/2007 10:57:32 AM |
| From: "Victor W. Gates" [Email Address Protection] |
Megan Kielman wrote: > Thank you for clarifying. I do have some follow up questions AND I > wanted to let you know that I do have a copy of Windows Internals but > some of it is greek to me and it helps me learn to talk to someone > about it. Also, in this example the /PAE switch is being used so that > the system can recognize the addition memory beyond 4GB. > > I understand that KM space is shared. For clarification, this is where > the non-paged, paged pool, and PTEs reside, correct? Can you explain > what aspects of a process will utilize paged, non-paged pool memory > and PTEs? > > You mentioned that each process will have its own UM memory space, so > for two processes, 4GB of UM will be used and for 3 processes, 6GB of > memory will be used. What happens when the 4th process comes online, > where will its memory come from now that we have all memory mapped? > What is causing your confusion is that you think each process will use 2GB always; each UM can be UP TO 2GB, but DO NOT need to be. So lets say you have 18 process, each using 300KB of UM, all 18 will fit onto the 6GB, if one of the process need more memory, or you start more process, then PAGING will take over, and make available more UM space. See the next post for more info on Paging. > > > > > the_el_vez wrote: >> Sorry - let me be more clear. Each process has a 4GB virtual address >> space. The lower 2GB are UM and the upper 2GB are KM. Each process >> has this property. However, almost all of the KM space in each >> process is mapped to the same backing physical memory. Whereas almost >> all of the UM space of each process is mapped to its own backing >> pages. So for example - if you have 2 processes - and mapped all the >> UM and KM space to RAM - you might expect to use 8GB of RAM - 2*2GB >> for the 2 processes UM space and 2*2GB for each of the processes KM >> space. But in fact you would only use around 6GB of RAM as the kernel >> space is a shared mapping between the 2 processes (and processes for >> that matter). If you used the /3GB switch in this scenario then you >> would use around 7GB or RAM - 3GB for each process's UM space and 1GB >> for the shared kernel mapping. >> >> Note that the reason I say "mostly" and "almost all" is because there >> are some pages that are shared between all processes in UM (i.e. >> read-only code pages, etc.). Also - some kernel pages are private to >> a process as well (i.e. page tables, etc.) - but generally speaking >> you can think of KM space as wholly shared amongst all processes. >> >> Does this make more sense? >> >> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >> news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >>> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode >>> and 6GB goes to UM? >>> >>> >>> >>> >>> Ben Voigt [C++ MVP] wrote: >>>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>>> You will really want to get a copy of "Windows Internals". It >>>>> covers all the basic concepts in Windows very well. >>>>> >>>>> In 32 bit windows you always have a 32 bit address space (4GB). >>>>> With 2GB going to UM and 2GB to kernel. If you use the 3GB switch >>>>> then you get 3GB of >>>> >>>> Of course that is per-process, so you could use all 8GB of memory >>>> with 3-4 processes running. >>>> >>>>> UM space if you link the app as "large address space aware". This >>>>> squashes the kernel down to 1GB which is bad. The additional ram >>>>> allows you to have more processes mapping memory to RAM. This is a >>>>> very confusing area as there are lots of seemingly overlapped >>>>> technologies (i.e AWE, PAE, 3GB, etc.). >>>>> >>>>> >>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM >>>>>> and WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>>> Kernel-mode and 6GB to User-mode? >>>>>> >>>>>> Megan |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/19/2007 5:48:44 PM |
| From: Megan Kielman [Email Address Protection] |
Victor - Thank you so much for clarifying. I was just about to ask that question next but you had already answered it!!! Megan Victor W. Gates wrote: > Megan Kielman wrote: >> Thank you for clarifying. I do have some follow up questions AND I >> wanted to let you know that I do have a copy of Windows Internals but >> some of it is greek to me and it helps me learn to talk to someone >> about it. Also, in this example the /PAE switch is being used so that >> the system can recognize the addition memory beyond 4GB. >> >> I understand that KM space is shared. For clarification, this is where >> the non-paged, paged pool, and PTEs reside, correct? Can you explain >> what aspects of a process will utilize paged, non-paged pool memory >> and PTEs? >> >> You mentioned that each process will have its own UM memory space, so >> for two processes, 4GB of UM will be used and for 3 processes, 6GB of >> memory will be used. What happens when the 4th process comes online, >> where will its memory come from now that we have all memory mapped? >> > What is causing your confusion is that you think each process will use > 2GB always; each UM can be UP TO 2GB, but DO NOT need to be. > So lets say you have 18 process, each using 300KB of UM, all 18 will fit > onto the 6GB, if one of the process need more memory, or you start more > process, then PAGING will take over, and make available more UM space. > > See the next post for more info on Paging. > >> >> >> >> >> the_el_vez wrote: >>> Sorry - let me be more clear. Each process has a 4GB virtual address >>> space. The lower 2GB are UM and the upper 2GB are KM. Each process >>> has this property. However, almost all of the KM space in each >>> process is mapped to the same backing physical memory. Whereas almost >>> all of the UM space of each process is mapped to its own backing >>> pages. So for example - if you have 2 processes - and mapped all the >>> UM and KM space to RAM - you might expect to use 8GB of RAM - 2*2GB >>> for the 2 processes UM space and 2*2GB for each of the processes KM >>> space. But in fact you would only use around 6GB of RAM as the kernel >>> space is a shared mapping between the 2 processes (and processes for >>> that matter). If you used the /3GB switch in this scenario then you >>> would use around 7GB or RAM - 3GB for each process's UM space and 1GB >>> for the shared kernel mapping. >>> >>> Note that the reason I say "mostly" and "almost all" is because there >>> are some pages that are shared between all processes in UM (i.e. >>> read-only code pages, etc.). Also - some kernel pages are private to >>> a process as well (i.e. page tables, etc.) - but generally speaking >>> you can think of KM space as wholly shared amongst all processes. >>> >>> Does this make more sense? >>> >>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>> news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >>>> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode >>>> and 6GB goes to UM? >>>> >>>> >>>> >>>> >>>> Ben Voigt [C++ MVP] wrote: >>>>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>>>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>>>> You will really want to get a copy of "Windows Internals". It >>>>>> covers all the basic concepts in Windows very well. >>>>>> >>>>>> In 32 bit windows you always have a 32 bit address space (4GB). >>>>>> With 2GB going to UM and 2GB to kernel. If you use the 3GB switch >>>>>> then you get 3GB of >>>>> >>>>> Of course that is per-process, so you could use all 8GB of memory >>>>> with 3-4 processes running. >>>>> >>>>>> UM space if you link the app as "large address space aware". This >>>>>> squashes the kernel down to 1GB which is bad. The additional ram >>>>>> allows you to have more processes mapping memory to RAM. This is a >>>>>> very confusing area as there are lots of seemingly overlapped >>>>>> technologies (i.e AWE, PAE, 3GB, etc.). >>>>>> >>>>>> >>>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM >>>>>>> and WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>>>> Kernel-mode and 6GB to User-mode? >>>>>>> >>>>>>> Megan |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/19/2007 5:50:48 PM |
| From: Megan Kielman [Email Address Protection] |
Yes this makes perfect sense. I really appreciate your time! My last question is regarding the memory pages. Each memory page can store 4KB of data, right? the_el_vez wrote: > Ok - so now we are getting somewhere. :) > > So - the designers of Windows (and all other modern OSes before them) > realized that if the OS wanted to support more than 1 or 2 processes - > it would require a HUGE amount of physical memory. The solution to this > problem is called paging or swapping. All processes UM space are mapped > using pageable memory. Only a small portion of a process's UM space is > actually mapped to RAM at any given moment. The rest of the space is > mapped to the page file (or other mapped files depending on the > process). When a process accesses a page that is not resident in RAM - > it causes the processor to issue a page fault. This is a KM event that > causes the Windows memory manager to jump into action and try to resolve > the situation. The memory manager examines the address that faulted and > looks to see if it is swapped out to the page file. If so - it finds (or > makes) a page of RAM free and then copies in that page from disk to RAM > and has the processor redo the instruction that faulted - which will now > succeed. So now you can have LOTS of programs all thinking they have > there own personal 2GB of RAM - but really have only a relatively small > amount of memory on the machine. Pretty cool huh! :D > > The set of pages that are actually in RAM for a given process at any > given moment is called the "Process Working Set". You can see this value > per process in the various tools that come with Windows or from the > sysinternals tools. > > Does this make more sense? > > "Megan Kielman" <megan.kielman@gmail.com> wrote in message > news:uISJOiGKIHA.748@TK2MSFTNGP04.phx.gbl... >> Thank you for clarifying. I do have some follow up questions AND I >> wanted to let you know that I do have a copy of Windows Internals but >> some of it is greek to me and it helps me learn to talk to someone >> about it. Also, in this example the /PAE switch is being used so that >> the system can recognize the addition memory beyond 4GB. >> >> I understand that KM space is shared. For clarification, this is where >> the non-paged, paged pool, and PTEs reside, correct? Can you explain >> what aspects of a process will utilize paged, non-paged pool memory >> and PTEs? >> >> You mentioned that each process will have its own UM memory space, so >> for two processes, 4GB of UM will be used and for 3 processes, 6GB of >> memory will be used. What happens when the 4th process comes online, >> where will its memory come from now that we have all memory mapped? >> >> >> >> >> >> >> the_el_vez wrote: >>> Sorry - let me be more clear. Each process has a 4GB virtual address >>> space. The lower 2GB are UM and the upper 2GB are KM. Each process >>> has this property. However, almost all of the KM space in each >>> process is mapped to the same backing physical memory. Whereas almost >>> all of the UM space of each process is mapped to its own backing >>> pages. So for example - if you have 2 processes - and mapped all the >>> UM and KM space to RAM - you might expect to use 8GB of RAM - 2*2GB >>> for the 2 processes UM space and 2*2GB for each of the processes KM >>> space. But in fact you would only use around 6GB of RAM as the kernel >>> space is a shared mapping between the 2 processes (and processes for >>> that matter). If you used the /3GB switch in this scenario then you >>> would use around 7GB or RAM - 3GB for each process's UM space and 1GB >>> for the shared kernel mapping. >>> >>> Note that the reason I say "mostly" and "almost all" is because there >>> are some pages that are shared between all processes in UM (i.e. >>> read-only code pages, etc.). Also - some kernel pages are private to >>> a process as well (i.e. page tables, etc.) - but generally speaking >>> you can think of KM space as wholly shared amongst all processes. >>> >>> Does this make more sense? >>> >>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>> news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >>>> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode >>>> and 6GB goes to UM? >>>> >>>> >>>> >>>> >>>> Ben Voigt [C++ MVP] wrote: >>>>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>>>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>>>> You will really want to get a copy of "Windows Internals". It >>>>>> covers all the basic concepts in Windows very well. >>>>>> >>>>>> In 32 bit windows you always have a 32 bit address space (4GB). >>>>>> With 2GB going to UM and 2GB to kernel. If you use the 3GB switch >>>>>> then you get 3GB of >>>>> >>>>> Of course that is per-process, so you could use all 8GB of memory >>>>> with 3-4 processes running. >>>>> >>>>>> UM space if you link the app as "large address space aware". This >>>>>> squashes the kernel down to 1GB which is bad. The additional ram >>>>>> allows you to have more processes mapping memory to RAM. This is a >>>>>> very confusing area as there are lots of seemingly overlapped >>>>>> technologies (i.e AWE, PAE, 3GB, etc.). >>>>>> >>>>>> >>>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM >>>>>>> and WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>>>> Kernel-mode and 6GB to User-mode? >>>>>>> >>>>>>> Megan >>>>> > |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/19/2007 6:17:10 PM |
| From: "David Craig" [Email Address Protection] |
Usually, but read "Windows Internals" as some mode can have larger pages. Also refer to the Intel CPU manuals for supported page sizes. Computer Science courses cover the concepts of virtual memory systems that have been used since the 1960's. Intel CPU manuals document the capabilities of their processors including paging and page table specifics. "Windows Internals" 4th edition documents how Windows uses the capabilities of the processors to provide their virtual memory implementation. Early Windows NT ran on processors with differing capabilities including page table sizes. Currently almost all processors are x86 and possibly x64 in design. For consumer Windows operating systems the Itanium is no longer supported, but it is supported for the server OS. "Megan Kielman" <megan.kielman@gmail.com> wrote in message news:%234csk9wKIHA.4712@TK2MSFTNGP04.phx.gbl... > Yes this makes perfect sense. I really appreciate your time! > > My last question is regarding the memory pages. Each memory page can store > 4KB of data, right? > > the_el_vez wrote: >> Ok - so now we are getting somewhere. :) >> >> So - the designers of Windows (and all other modern OSes before them) >> realized that if the OS wanted to support more than 1 or 2 processes - it >> would require a HUGE amount of physical memory. The solution to this >> problem is called paging or swapping. All processes UM space are mapped >> using pageable memory. Only a small portion of a process's UM space is >> actually mapped to RAM at any given moment. The rest of the space is >> mapped to the page file (or other mapped files depending on the process). >> When a process accesses a page that is not resident in RAM - it causes >> the processor to issue a page fault. This is a KM event that causes the >> Windows memory manager to jump into action and try to resolve the >> situation. The memory manager examines the address that faulted and looks >> to see if it is swapped out to the page file. If so - it finds (or makes) >> a page of RAM free and then copies in that page from disk to RAM and has >> the processor redo the instruction that faulted - which will now succeed. >> So now you can have LOTS of programs all thinking they have there own >> personal 2GB of RAM - but really have only a relatively small amount of >> memory on the machine. Pretty cool huh! :D >> >> The set of pages that are actually in RAM for a given process at any >> given moment is called the "Process Working Set". You can see this value >> per process in the various tools that come with Windows or from the >> sysinternals tools. >> >> Does this make more sense? >> >> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >> news:uISJOiGKIHA.748@TK2MSFTNGP04.phx.gbl... >>> Thank you for clarifying. I do have some follow up questions AND I >>> wanted to let you know that I do have a copy of Windows Internals but >>> some of it is greek to me and it helps me learn to talk to someone about >>> it. Also, in this example the /PAE switch is being used so that the >>> system can recognize the addition memory beyond 4GB. >>> >>> I understand that KM space is shared. For clarification, this is where >>> the non-paged, paged pool, and PTEs reside, correct? Can you explain >>> what aspects of a process will utilize paged, non-paged pool memory and >>> PTEs? >>> >>> You mentioned that each process will have its own UM memory space, so >>> for two processes, 4GB of UM will be used and for 3 processes, 6GB of >>> memory will be used. What happens when the 4th process comes online, >>> where will its memory come from now that we have all memory mapped? >>> >>> >>> >>> >>> >>> >>> the_el_vez wrote: >>>> Sorry - let me be more clear. Each process has a 4GB virtual address >>>> space. The lower 2GB are UM and the upper 2GB are KM. Each process has >>>> this property. However, almost all of the KM space in each process is >>>> mapped to the same backing physical memory. Whereas almost all of the >>>> UM space of each process is mapped to its own backing pages. So for >>>> example - if you have 2 processes - and mapped all the UM and KM space >>>> to RAM - you might expect to use 8GB of RAM - 2*2GB for the 2 processes >>>> UM space and 2*2GB for each of the processes KM space. But in fact you >>>> would only use around 6GB of RAM as the kernel space is a shared >>>> mapping between the 2 processes (and processes for that matter). If you >>>> used the /3GB switch in this scenario then you would use around 7GB or >>>> RAM - 3GB for each process's UM space and 1GB for the shared kernel >>>> mapping. >>>> >>>> Note that the reason I say "mostly" and "almost all" is because there >>>> are some pages that are shared between all processes in UM (i.e. >>>> read-only code pages, etc.). Also - some kernel pages are private to a >>>> process as well (i.e. page tables, etc.) - but generally speaking you >>>> can think of KM space as wholly shared amongst all processes. >>>> >>>> Does this make more sense? >>>> >>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>> news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >>>>> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and >>>>> 6GB goes to UM? >>>>> >>>>> >>>>> >>>>> >>>>> Ben Voigt [C++ MVP] wrote: >>>>>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>>>>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>>>>> You will really want to get a copy of "Windows Internals". It covers >>>>>>> all the basic concepts in Windows very well. >>>>>>> >>>>>>> In 32 bit windows you always have a 32 bit address space (4GB). With >>>>>>> 2GB going to UM and 2GB to kernel. If you use the 3GB switch then >>>>>>> you get 3GB of >>>>>> >>>>>> Of course that is per-process, so you could use all 8GB of memory >>>>>> with 3-4 processes running. >>>>>> >>>>>>> UM space if you link the app as "large address space aware". This >>>>>>> squashes the kernel down to 1GB which is bad. The additional ram >>>>>>> allows you to have more processes mapping memory to RAM. This is a >>>>>>> very confusing area as there are lots of seemingly overlapped >>>>>>> technologies (i.e AWE, PAE, 3GB, etc.). >>>>>>> >>>>>>> >>>>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>>>>>>> WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>>>>> Kernel-mode and 6GB to User-mode? >>>>>>>> >>>>>>>> Megan >>>>>> >> |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/20/2007 8:25:04 AM |
| From: Megan Kielman [Email Address Protection] |
Thank you! David Craig wrote: > Usually, but read "Windows Internals" as some mode can have larger pages. > Also refer to the Intel CPU manuals for supported page sizes. Computer > Science courses cover the concepts of virtual memory systems that have been > used since the 1960's. Intel CPU manuals document the capabilities of their > processors including paging and page table specifics. "Windows Internals" > 4th edition documents how Windows uses the capabilities of the processors to > provide their virtual memory implementation. Early Windows NT ran on > processors with differing capabilities including page table sizes. > Currently almost all processors are x86 and possibly x64 in design. For > consumer Windows operating systems the Itanium is no longer supported, but > it is supported for the server OS. > > > "Megan Kielman" <megan.kielman@gmail.com> wrote in message > news:%234csk9wKIHA.4712@TK2MSFTNGP04.phx.gbl... >> Yes this makes perfect sense. I really appreciate your time! >> >> My last question is regarding the memory pages. Each memory page can store >> 4KB of data, right? >> >> the_el_vez wrote: >>> Ok - so now we are getting somewhere. :) >>> >>> So - the designers of Windows (and all other modern OSes before them) >>> realized that if the OS wanted to support more than 1 or 2 processes - it >>> would require a HUGE amount of physical memory. The solution to this >>> problem is called paging or swapping. All processes UM space are mapped >>> using pageable memory. Only a small portion of a process's UM space is >>> actually mapped to RAM at any given moment. The rest of the space is >>> mapped to the page file (or other mapped files depending on the process). >>> When a process accesses a page that is not resident in RAM - it causes >>> the processor to issue a page fault. This is a KM event that causes the >>> Windows memory manager to jump into action and try to resolve the >>> situation. The memory manager examines the address that faulted and looks >>> to see if it is swapped out to the page file. If so - it finds (or makes) >>> a page of RAM free and then copies in that page from disk to RAM and has >>> the processor redo the instruction that faulted - which will now succeed. >>> So now you can have LOTS of programs all thinking they have there own >>> personal 2GB of RAM - but really have only a relatively small amount of >>> memory on the machine. Pretty cool huh! :D >>> >>> The set of pages that are actually in RAM for a given process at any >>> given moment is called the "Process Working Set". You can see this value >>> per process in the various tools that come with Windows or from the >>> sysinternals tools. >>> >>> Does this make more sense? >>> >>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>> news:uISJOiGKIHA.748@TK2MSFTNGP04.phx.gbl... >>>> Thank you for clarifying. I do have some follow up questions AND I >>>> wanted to let you know that I do have a copy of Windows Internals but >>>> some of it is greek to me and it helps me learn to talk to someone about >>>> it. Also, in this example the /PAE switch is being used so that the >>>> system can recognize the addition memory beyond 4GB. >>>> >>>> I understand that KM space is shared. For clarification, this is where >>>> the non-paged, paged pool, and PTEs reside, correct? Can you explain >>>> what aspects of a process will utilize paged, non-paged pool memory and >>>> PTEs? >>>> >>>> You mentioned that each process will have its own UM memory space, so >>>> for two processes, 4GB of UM will be used and for 3 processes, 6GB of >>>> memory will be used. What happens when the 4th process comes online, >>>> where will its memory come from now that we have all memory mapped? >>>> >>>> >>>> >>>> >>>> >>>> >>>> the_el_vez wrote: >>>>> Sorry - let me be more clear. Each process has a 4GB virtual address >>>>> space. The lower 2GB are UM and the upper 2GB are KM. Each process has >>>>> this property. However, almost all of the KM space in each process is >>>>> mapped to the same backing physical memory. Whereas almost all of the >>>>> UM space of each process is mapped to its own backing pages. So for >>>>> example - if you have 2 processes - and mapped all the UM and KM space >>>>> to RAM - you might expect to use 8GB of RAM - 2*2GB for the 2 processes >>>>> UM space and 2*2GB for each of the processes KM space. But in fact you >>>>> would only use around 6GB of RAM as the kernel space is a shared >>>>> mapping between the 2 processes (and processes for that matter). If you >>>>> used the /3GB switch in this scenario then you would use around 7GB or >>>>> RAM - 3GB for each process's UM space and 1GB for the shared kernel >>>>> mapping. >>>>> >>>>> Note that the reason I say "mostly" and "almost all" is because there >>>>> are some pages that are shared between all processes in UM (i.e. >>>>> read-only code pages, etc.). Also - some kernel pages are private to a >>>>> process as well (i.e. page tables, etc.) - but generally speaking you >>>>> can think of KM space as wholly shared amongst all processes. >>>>> >>>>> Does this make more sense? >>>>> >>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>> news:u486tv5JIHA.2480@TK2MSFTNGP05.phx.gbl... >>>>>> Ok so for clarification without the /3GB, 2GB goes to Kernel Mode and >>>>>> 6GB goes to UM? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Ben Voigt [C++ MVP] wrote: >>>>>>> "the_el_vez" <jonathanm@mindspring.com> wrote in message >>>>>>> news:F97472C8-F598-4D39-A241-45CD75992828@microsoft.com... >>>>>>>> You will really want to get a copy of "Windows Internals". It covers >>>>>>>> all the basic concepts in Windows very well. >>>>>>>> >>>>>>>> In 32 bit windows you always have a 32 bit address space (4GB). With >>>>>>>> 2GB going to UM and 2GB to kernel. If you use the 3GB switch then >>>>>>>> you get 3GB of >>>>>>> Of course that is per-process, so you could use all 8GB of memory >>>>>>> with 3-4 processes running. >>>>>>> >>>>>>>> UM space if you link the app as "large address space aware". This >>>>>>>> squashes the kernel down to 1GB which is bad. The additional ram >>>>>>>> allows you to have more processes mapping memory to RAM. This is a >>>>>>>> very confusing area as there are lots of seemingly overlapped >>>>>>>> technologies (i.e AWE, PAE, 3GB, etc.). >>>>>>>> >>>>>>>> >>>>>>>> "Megan Kielman" <megan.kielman@gmail.com> wrote in message >>>>>>>> news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>>>>>>>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>>>>>>>> WITHOUT the /3GB switch, how is the memory split up. 2GB to >>>>>>>>> Kernel-mode and 6GB to User-mode? >>>>>>>>> >>>>>>>>> Megan > > |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/20/2007 11:33:28 AM |
| From: "James Matthews" [Email Address Protection] |
It depends on what is required! -- http://www.goldwatches.com/movado--watches.html http://www.jewelerslounge.com/ "Megan Kielman" <megan.kielman@gmail.com> wrote in message news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... > If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and > WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode > and 6GB to User-mode? > > Megan |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/20/2007 2:32:37 PM |
| From: DevilsPGD [Email Address Protection] |
(Fixed top posting) In message <FCA9CFDB-6554-4483-9E47-4A4ACDA1EE5D@microsoft.com> "James Matthews" <jamesmatt18@gmail.com> wrote: >"Megan Kielman" <megan.kielman@gmail.com> wrote in message >news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >> and 6GB to User-mode? >> >> Megan > >It depends on what is required! Did you even read the post? The /3GB switch controls how much memory is assigned to the kernel and how much is assigned to user-mode, this decision cannot be made on the fly, and cannot be made by the machine based on what is required. |
| Back |
| Subject: Re: x86 Memory Question |
| Group: microsoft.public.winternals |
| Date: 11/28/2007 1:45:30 PM |
| From: "Ben Voigt [C++ MVP]" [Email Address Protection] |
"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message news:0bk6k3h24sbik7s7kbilsihl1gbp1r95co@4ax.com... > (Fixed top posting) > > In message <FCA9CFDB-6554-4483-9E47-4A4ACDA1EE5D@microsoft.com> "James > Matthews" <jamesmatt18@gmail.com> wrote: > >>"Megan Kielman" <megan.kielman@gmail.com> wrote in message >>news:%23QZKMcgJIHA.1020@TK2MSFTNGP05.phx.gbl... >>> If I have an x86 Windows 2003 Enterprise system with 8GB of RAM and >>> WITHOUT the /3GB switch, how is the memory split up. 2GB to Kernel-mode >>> and 6GB to User-mode? >>> >>> Megan >> >>It depends on what is required! > > Did you even read the post? The /3GB switch controls how much memory is > assigned to the kernel and how much is assigned to user-mode, this > decision cannot be made on the fly, and cannot be made by the machine > based on what is required. No, the /3GB switch determines how virtual address space is allocated, not how physical memory is allocated. Physical memory allocation, except kernel non-paged pool, is done dynamically. |
| Back |