I've read an interesting article at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796(v=vs.85).aspx. It states that:
Physical Address Extension (PAE) is a processor feature that enables x86 processors to access more than 4 GB of physical memory on capable versions of Windows.
PAE does not change the amount of virtual address space available to a process. Each process running in 32-bit Windows is still limited to a 4 GB virtual address space.
Would you please tell me what advantages of this feature are? Is it only useful for reducing amount of time OSs handle paging?
PAE is useful when you have more than one application running, and consuming memory. Like if you have 16GB of RAM on a 32bit machine, without PAE, you'd be able to use only 4GB for all applications, and the OS itself. But with PAE, you could have each process its own 32 bit address space, so you could use all the 16GB of RAM, just not from one process...
Put the DB and the application server instances on the same box for example, and it becomes useful.
EDIT
In the first approach, this was not clear: one does not need to have a 64bit CPU to be able to use PAE! From Pentium Pro up, the CPU should be able to use it:
In computing, Physical Address Extension (PAE) is a feature to allow 32-bit x86 processors to access a physical address space (including random access memory and memory mapped devices) larger than 4 gigabytes.
(From: Wikipedia: Physical Address Extension)
Also recommended to read:
Wikipedia: 3GB barrier
Serverfault: Which CPUs do/do not support PAE
To leverage PAE you do need a 64-bit processor. and bus size is 36 bits.
It's like your hardware is capable of accessing more than 4GB Memory, but intentionally/unintentionally you have installed a 32-bit operating system, which by default does not allow you to access beyond 0xffffffff, so put additional kernel module which will let you access everything.
Related
I have an exam tomorrow on virtual memory address translation and I'm rather confused on this topic. I know the CPU will generate a virtual address to then access a physical address. So if we have a system with 32 bit virtual addresses, and 64 bit physical addresses, then the pointers for user level processes I'm guessing will be 8 bytes.
My logic is because the virtual address is being translated to the physical address, so this number will always be coming from the physical address.
No, user-space processes work only with virtual addresses (32-bit in your example).
The memory they "see" is their own private virtual address space. (They can make system calls like mmap and munmap to request that pages in that address-space be backed by files, or by anonymous RAM like for C malloc.) But they don't know anything about where in physical memory those pages are located.
The OS can even "fake it" by paging out some of their pages to swap space / page file, and handling the page fault if the process touches such a page by doing I/O to bring it back in and then waking up the process to rerun the load or store instruction that page faulted.
Hardware translates virtual addresses to physical addresses on every memory access. To make this fast, a TLB caches recently-used translations. On a TLB miss, hardware does a "page walk", reading the page tables to find the right virtual page->physical page translation.
The OS manages the page tables, choosing any physical page as "backing" for a virtual page.
Physical addresses wider than virtual?
Under a multi-tasking OS, multiple processes can be running. Each one has its own 32-bit (4GiB) virtual address space.
The size of physical address space limits how much RAM you can put in a machine total, and can be different from how much any single process can use at once. Changing page tables is faster than reading from disk, so even if it can't all be mapped at once, a kernel can still make use of lots of physical RAM for pagecache (cache of file contents from disk).
More importantly, multiple processes can be running, each with their own up-to-4GiB of virtual address space backed by physical memory, up to the amount of physical RAM in the system. On a CPU with multiple cores, these can be running simultaneously, truly allowing simultaneous use of more than 4GB of RAM. But not by any single process.
x86 is a good example here: Running an x86-64 kernel with 32-bit user-space gives us pretty much the situation you describe. (A 64-bit kernel can use 64-bit virtual addresses, but nevermind that, just look at user-space.)
You can have several processes each using about 4GiB of physical RAM.
The x86-64 page-table format has room for physical addresses as wide as 52-bit, although current HW doesn't use that many. (Only as wide as the amount of RAM it actually supports attaching. Saves bits in the TLBs, and other parts of the CPU). https://en.wikipedia.org/wiki/X86-64#Architectural_features
Before x86-64, 32-bit x86 kernels could use the same page-table format but with 36-bit physical addresses, on CPUs from Pentium Pro and later.
https://en.wikipedia.org/wiki/Physical_Address_Extension. That allowed up to 64GB of physical RAM. (A 32-bit kernel would typically reserve 1 or 2GB of virtual address space for itself so each process could really only use up to 3 or 2GB, but it's the same idea. Not a problem for 32-bit user-space under a 64-bit kernel though, so that made a simpler example.)
Virtual addresses are visible to user-level processes. They never should never see the physical address. So if virtual addresses are 32-bit, pointers in user-level processes are also 32-bit, i.e. 4 bytes.
The system/kernel then needs to do the translation somehow. It will know the virtual address and must translate it to the physical address, so it will eventually have a physical pointer, 64-bit = 8 byte. But once again, this address/pointer are for "internal use" only.
In practice though, you will have virtual and physical addresses of the same size, matching the word size of the CPU and its architecture (x86 vs x86_64). A virtual to pyhsicial translation will normally need to happen in a page fault, which happens when a user-level process attempts to access memory that is not loaded. To access it in the first place, it needs to have e.g. dereferenced a pointer pointing to that address, which would be done with a memory access instruction of the particular CPU architecture, which is done with word-sized addresses.
The programmer will only see virtual addresses. The physical address space is opaque to the programmer and the user. Therefore, size of a pointer is dependent on the size of the virtual address. In the particular case you have given, the maximum amount of memory your system can consume is dictated by your virtual address space. This is why 32-bit OS on 64-bit hardware is limited to a maximum of 4 gigs of memory. But, in the case of a 64-bit virtual address, even if we have insufficient RAM, we can offload some of the pages to the secondary storage to give the illusion that we have more RAM available. In the case, the page is located in the secondary memory, a page fault occurs and the page is transferred to RAM.
Edit : As Peter said in the comments, the virtual address limit affects the maximum memory a Process can consume.
I have read that Operating System is loaded in main memory (RAM) when computer boots up. Also, application programs are loaded into main memory (RAM) for execution. How do both of these run simultaneously in main memory? Does the operating system stop its execution when an application program is running?
I don't know of a good overview of these areas, so I'll try to help.
Memory (RAM) can be visualized as a collection of lockers. Each locker can store something independently of all other lockers. Each locker has a number, so you can find a particular locker easily. In RAM, the locker is a byte that can store a value between zero and 255, and the locker number is an address. Better than a locker; you can open the byte at address zero, then the byte at address 1000000 instantly. You don't have to walk down a long hallway. That is what the R in RAM refers to: Random, as in Random Access Memory. Essentially every location takes the same amount of time to access.
Machines have a lot of RAM, on the order of billions of bytes. Even very big operating systems do not need all of RAM; if they require 50 million bytes, that is only 50 / 1000 or 5% of what is now considered a small system. That leaves 950 million bytes for programs to use. If every program was as big as the operating system, you could run 950/50 = 19 of them. There are tricks to permit running even more.
One of the fundamental jobs of the operating system is to provision resources like RAM to applications, and make sure that applications cannot snoop on or modify each others RAM without prior arrangement. To do this, the operating system typically uses a trick where program addresses are indirectly translated to RAM addresses under control of the operating system. This way, all applications can think they have ram at (say) address 4194304. This trick is called an MMU (Memory Management Unit), and the details start to explode at this point.
Review:
RAM is a collection of places to store numbers, and each storage place has a unique address.
There is lots of RAM, so we just have to divvy it up between applications.
We can keep applications RAM separate and secret from other applications.
The operating system only uses a relatively small amount of RAM.
During the process of booting, CPU reads address of system BIOS from the Reset Vector and jumps to the location where BIOS is stored. My question here is:
*As BIOS is stored on some external memory like EEPROM (and not on main memory) , how does CPU access this external memory ?
*Is this external memory already mapped to some region of main memory?
and does the CPU just jump to this mapped region to access BIOS instructions
Or it actually accesses the instructions from external memory where BIOS is stored?
First I can refer you to a detailed article:
https://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/#gref
But I will summarize here:
When CPU is "resetted", the reset vector interrupt (a specific memory address - 0xFFFFFFF0H) is executed - and the ROM content has to be there at that specific address.
Intel Reset Vector
How is the BIOS ROM mapped into address space on PC?
Who loads the BIOS and the memory map during boot-up
0xffff0 and the BIOS (hardwired address mapping is also explained/emphasized here)
When BIOS is executed, it will also initialize hardware like VGA, and initialize DRAM memory. Sometimes RAM memory and BIOS may overlapped, and usually the OS will takeover and reimplement all the functionalities of the BIOS (whis is specific to each motherboard).
What information does BIOS load into RAM?
https://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/
Diagram below illustrate how motherboard designer will design the address ranges usable by the different hardware peripherals to lie in certain ranges, and the OS then has the responsibilities to allocate RAM ranges to lie in the unused by hardware regions. Don't forget that each core (for 32-bit) can only access 4GB memory - but phyical memory available can be much more than that. This is where pagetable comes in.
Once the pagetable is setup, then only the TLB and pagetable can be used - which is to provide indirect and efficient access to the RAM memory.
Normally the CPU access the data and information through by interfacing with the SPI in turn communicates with the EEEPROM to fulfill the task requested or deliver the information requested by the CPU.
And no, the external memory is not mapped anywhere and no the CPU does not just jump to it. It communicates with what it or the BIOS needs through SPI or I^C depending on the age of the machine.
I'm studying OS and I have a doubt about physical and logical addresses.
If logical addresses do not exist in real and are only used to indicate physical addresses, why do we use logical addresses at all? Why not directly physical address?
Thanks in advance!
One good example of why an operating system uses a logical address is the concept of virtual memory. For example, a process can be running in Windows which requires 100MB of RAM to execute. Without virtual memory, if this amount of RAM were not available, the process could not run. With virtual memory, the Windows OS can tell the process that the memory it needs is available. However, the OS cannot expose 100MB of physical memory because it does not exist. Instead, the OS will expose 100MB of logical memory. Some or all of this memory may not map to a physical address. Instead, it might map to disk or another location.
Another reason is fragmentation.
Lets say you have 100 MB of memory and the first three processes need 20 MB each. You give them the memory they want, they run and then the second one terminates. You are left with 60 MB of free memory, but any process that wants a sequential address space of 50 MB can't have it.
Using logical addresses gives you that ability.
One of the major benefits of using logical addresses (and in fact, similar thinking is true for most naming abstractions such as domain names in the networking context, file descriptors, etc.) is that programs can be written in a way that is agnostic to the actual layout of physical memory. That is, you can write your program such that data is stored in say, address 0xdeadbeef (this is a logical address), and your program would work just fine (the MMU or a boot loader that performs binary translation would convert the logical address into an appropriate physical address at run-time or at boot time).
In the above scenario, if your program were written to use physical addresses from the get go, you would run the risk of running into conflicts with other processes that use the same address to store data (e.g., other instances of your program).
Could someone tell me where is the code of BIOS loaded when the CPU reset ,and how much memory does it take for different CPU architecture?I only know 64KB.
The BIOS is located in read-only memory (ROM). An x86 CPU automatically starts executing instructions at 4GB minus 16 bytes. This address is mapped to the system ROM. For more information about the x86 bootup process, see http://en.wikipedia.org/wiki/BIOS#System_startup
As for how much memory BIOS takes, it depends on many things. It isn't just dependent on the CPU architecture, but it is dependent on the vendor of the system. Different vendors use different BIOSes that may have different sizes. According to Wikipedia, "BIOS versions now exist with sizes up to 16 megabytes" so perhaps that answers your question about the size of BIOS.