It is known that there are different kinds of Virtual-address translations (x86) with the help of MMU such as Segmentation, Paging, Combined Segmentation-Paging (Paged segmentation, Segmented Paging), etc. Each having its own advantages and disadvantages.
My Questions:
1) Are general Operating systems like Linux/Windows use only one particular technique (like Paging)?
2) If 2 or more techniques are available for a given OS, when & where each one will be used?
Can we customize according to our needs?
3) If 'Paging' only is used, then x86's segment registers are used in what ways?
In general, modern operating systems on x86 use paging and not segmentation. This means the base address of segment registers is set to zero and the segment limit is set to the maximum. Paging is used to map virtual addresses to physical addresses, this gives the OS fine grained control of the address space of a process, protection between processes, and protection between privileged (kernel) and user address space. Segments are still used in x86 for special purposes:
to run legacy operating systems and applications in a virtual environment
to efficiently access thread local storage for each thread in a multithreaded application (with thanks to #PaulA.Clayton for pointing this out).
Microsoft Windows switched from segmentation to a flat, linear memory model with Windows 95.
http://technet.microsoft.com/en-us/library/cc751120.aspx
Windows 95 addresses this issue by using the 32-bit capabilities of the 80386 (and above) processor architecture to support a flat, linear memory model for 32-bit operating system functionality and Win32-based applications. A linear addressing model simplifies the development process for application vendors, and removes the performance penalties imposed by the segmented memory architecture.
In order to run old Win16 applications (Windows 3.1) Windows 95 ran a 16-bit virtual machine where all Win16 applications ran. Newer, 32-bit applications ran in separate address spaces using the paging facility of the MMU.
Here's the relevant description from the link above
Related
As I was reading through the kernel source code I noticed that a mapping between the physical core id and the virtual core number is being created. This could be because there is some degree of uncertainty in the order in which the cores are brought up.
In a multi-core system, which physical core is the first to boot? Is it always physical core #0? Does this hold for x86, x64, ARM and ARM64?
According to the Intel SDM, in recent Intel processors the selection of the bootstrap processor (BSP) is handled either "through a special system bus cycle" or "by platform-specific arrangement of the combination of hardware, BIOS, and/or configuration input options."
In my experience (with Intel processors only), the BSP always has APIC ID 0 (although this is not guaranteed). However, I don't know whether that means that it is always the same physical core within the processor, or even if there is any way to tell.
For more information, see section 8.4 of the Intel SDM, volume 3A.
Involving the Windows operating system, a lot of things use the number 32, especially with Win32. I see it in everything from system folders:
C:\Windows\System32\
to system files:
C:\Windows\System32\win32k.sys
to Windows app development:
Develop a Win32 Application
The significance of the number 32 and computers makes me think 32-bit processors, but, if this is correct, why is there a need to explicitly mention 32-bit systems?
Googling around brought me to the Win32 API. This is, I presume, the main cause of its frequent use, but that doesn't change my question. The Windows operating system works perfectly fine on 64-bit systems.
Is Windows specialized for 32-bit systems?
Or is this just a historical thing (i.e. Windows and its API were developed before the 64-bit system emerged)?
Before Win32 there was Win16 (although perhaps maybe not using that name), and running 32-bit code was a special feature or it had special requirements, especially your CPU had to be able to do so.
Intel 8086 was a 16-bit CPU with 20-bit address space.
Intel 80286 was a 16-bit CPU with 24-bit address space.
Intel 80386 was full 32-bit, both registers and address space.
In my computer its running 32bit OS on the 64bit processor. So all the application installed are 32bit and my computer having a 2GB RAM. If I install a 64bit OS while keeping the same 32bit applications, will this improve the performance?? Or is there any disadvantage?
Talking about 32-bit and 64-bit software means that such software was developed in order to take advantage of CPUs with 32-bit or 64-bit registers size.
Registers are tiny portions of memory (NOT the RAM) used directly by a processing unit to temporarily save operations results (kind of variables), e.g. when summing two numbers the ALU reads from two registers, performs the operation and writes the answer in another register. The bigger those registers, the bigger values it can handle. A 32-bit processor has registers than can handle values up to 32 bits of size, as well as 64-bit processors can deal with numbers of a double size than 32-bit-based processors, which
results in 2^32 more values.
A 32-bit OS is an OS than works performing CPU operations on a machine with 32-bit CPU registers; a 64-bit OS works fine on 64-bit processors, but not on 32-bit ones because their registers are too small for such OS.
As a program runs on an OS, 32-bit apps will run (well, most times they do) on a 64-bit OS albeit they will use only half of any CPU register they need, simply because the program was designed not to deal with values bigger than 2^32 bit: this means that a 32-bit app running on a 64-bit OS will run without getting any particular performance improvement. As well, a 64-bit app will never run on a 32-bit OS because it needs more resources than those actually available.
Hope I was clear and correct enough, I studied processor architectures years ago...
This applies for a 64-bit app on x86/x86_64:
The 64-bit system will consume more RAM and most importantly cache because the larger pointers. This may be a performance bottleneck in case there are lots of pointers.
The 64-bit system will give you twice as many registers, twice as large. This makes it possible to store more variables in registers, which will be a performance gain.
So the choice may depend on which application you decide to benchmark.
The point of 64 bit is that apps can use more than 2gb of virtual memory. If you have more than 4gb of ram and your apps need to use more than 2gb of memory (sql server!) then potentially there will be a performance memory (because it can store more pages in memory rather than reading them from disk)
If this isn't the case and you have the same amount of memory then you won't get a performance increase and possibly a slight decrease as (assuming you are on windows here) to handle 32 bit apps working on a 64 bit o/s there is a complex system of redirections that happen (app asks for system32 and is sent to syswow64) - some of these are simple but some like the com registration lookups can cause many reg opens under the hood (do a regopen for a clsid that doesn't exists and see how many kernel32 makes on your behalf using procmon!).
So unless you have a very specific use case, which it sounds like you don't, it won't be faster
Given a 32-bit/64-bit processor can a 4GB process run on 2GB RAM. Will it use virtual memory or it wont run at all?
This is HIGHLY platform dependent. On many 32bit OS's, no single process can ever use more than 2GB of memory, regardless of the physical memory installed or virtual memory allocated.
For example, my work computers use 32bit Linux with PAE (Physical Address Extensions) to allow it to have 16GB of RAM installed. The 2GB per process limit still applies however. Having the extra RAM simply allows me to have more individual processes running. 32bit Windows is the same way.
64bit OS's are more of a mixed bag. 64bit Linux will allow individual processes to map memory well in excess of 32GB (but again, varies from Kernel to Kernel). You will be limited only by the amount of Swap (Linux virtual memory) you have. 64bit Windows is a complete crap shoot. Certain versions will only allow 2GB per process, but most will allow >32GB limited only by the amount of Page File the user has allocated.
Microsoft provides a useful table breaking down the various memory limits on various OS versions/editions. Unfortunately there is no such table that I can find with cursory searching for Linux since it is so fragmented.
Short answer: Depends on the system.
Most 32-bit systems have a limitation of 2GB per process. If your system allows >2GB per process, then we can move on to the next part of your question.
Most modern systems use Virtual Memory. Yet, there are some constrained (and various old) systems that would just run out of space and make you cry. I believe uClinux supports both MMU and MMU-less architectures. Most 32-bit processors have a MMU (a few don't, see ARM Cortex-M0) and a handful of 16-bit or 8-bit have it as well (see Atmel ATtiny13A-MMU and Atari MMU).
Any process that needs more memory than is physically available will require a form of Memory Swap (e.g., a partition or file).
Virtual Memory is divided in pages. At some point, a page reside either in RAM or in Swap. Any attempt to access a memory page that's not loaded in RAM will trigger an interruption called Page Fault, which is handled by the kernel.
A 64-bit process needing 4GB on a 64-bit OS can generally run in 2GB of physical RAM, by using virtual memory, assuming disk swap space is available, but performance will be severely impacted if all of that memory is frequently accessed.
A 32-bit process can't address exactly 4GB of memory in practice (some address space overhead is required by the operating system), so it won't run. Depending on the OS, it can probably run a process that needs > 2GB and < 3-4GB.
What is the maximum size a process can take on 32 bit processor on windows machine?
Can a process size be more than 4GB in any case?
Let's assume you are talking about virtual memory size, "process size" doesn't mean anything.
A 32-bit process can consume up to two gigabytes of address space on a 32-bit operating system.
A 32-bit process can consume up to three gigabytes of address space on a 32-bit operating system when it is booted with the /3GB boot option and it is linked with the /LARGEADDRESSAWARE linker option. This boot option is rarely available these days, particularly video adapters consume too much physical address space to leave enough room for the operating system and file system cache.
A 32-bit process can consume up to four gigabytes of address space on a 64-bit operating system, as long as it is linked with the /LARGEADDRESSAWARE linker option
A 64-bit process can consume an amount of virtual address space on a 64-bit operating system that's limited by the maximum size of the paging file. The absolute maximum is further limited by the OS edition, as documented here.
You are liable to run into other limitations. This is all well explored in Mark Russinovich' blog series titled "Pushing the limits". The virtual memory limits are explored in this one.