How would I go about setting the page size in memory for OS X Yosemite?
If I enter pagesize into terminal I get 4096. Is there a way I can modify this?
Short answer: No.
The page size is specific to your architecture and cannot generally be changed by a user at run-time. Intel x86 processors all use a page size of 4 KiB.
Longer answer:
Your CPU may also support larger pages, like 2 MiB, and 1 GiB. (See Huge Pages on Wikipedia.) However, it is completely up to your OS kernel to manage how pages of memory are mapped into various address spaces.
Few userspace APIs concern themselves with the platform's page size. The ones that do, however (e.g. mmap) are written to the least-common-denominator of the available page sizes, because you can't guarantee that a larger page size will be used for a particular page. For this reason, the "page size" exposed to userspace is a simple single value, like 4 KiB.
On Linux, there is some "control" over this mechanism. Check out:
Huge pages part 1 (Introduction) [LWN.net]
Huge pages part 2: Interfaces [LWN.net]
hugetlbpage.txt [kernel.org]
Hugepages [Debian Wiki]
I have no idea if OS X supports this. Searches for OS X hugepages came up thin.
Related
I tried solving the following question
Consider a machine with 128MiB (i.e. 2^27 bytes) of main memory and an MMU which has a page size of 8KiB (i.e.2^13 bytes). The operating system provides demand paging to a large spinning disk.
Viewing this paging system as another layer of caching below the processor’s last-level cache (LLC), answer following questions regarding the characteristics of this “cache”:
Line size in bytes? 2^13 (every page has 2^13 bytes)
Associativity? Full Associative
Number of lines in cache? 2^14 (Memory size / page size)
Tag size in bits? 14 (Number of lines in cache is 2^14 which gives us 14 bits for tag)
Replacement policy? I am not sure at all (maybe clock algorithm which approximates LRU)
Writeback or write-through? write back (It is not consistent with Disk at all times)
Write-allocate? yes, because after page fault we bring the page to memory for both writing and reading
Exclusivity/Inclusivity? I think non-inclusive and non exclusive (NINE), maybe because memory mapped files are partially in memory and partially in swap file or ELF file (program text). Forexample stack of process is only in memory except when we run out of memory and send it to a swap file. Am I right?
I would be glad if someone checked my answers and help me solve this correctly, Thanks! Sorry, if this is not the place to ask these kind of questions
To start; your answers for line size, associativity and number of lines are right.
Tag size in bits? 14 (Number of lines in cache is 2^14 which gives us 14 bits for tag)
Tag size would be "location on disk / line size", plus some other bits (e.g. for managing the replacement policy). We don't know how big the disk is (other than "large").
However; it's possibly not unreasonable to work this out backwards - start from the assumption that the OS was designed to support a wide range of different hard disk sizes and that the tag is a nice "power of 2"; then assume that 4 bits are used for other purposes (e.g. "age" for LRU). If the tag is 32 bits (a very common "power of 2") then it would imply the OS could support a maximum disk size of 2 TiB ("1 << (32-4) * 8 KiB"), which is (keeping "future proofing" in mind) a little too small for an OS designed in the last 10 years or so. The next larger "power of 2" is 64 bits, which is very likely for modern hardware, but less likely for older hardware (e.g. 32-bit CPUs, smaller disks). Based on "128 MiB of RAM" I'd suspect that the hardware is very old (e.g. normal desktop/server systems started having more than 128 MiB in the late 1990s), so I'd go with "32 bit tag".
Replacement policy? I am not sure at all (maybe clock algorithm which approximates LRU)
Writeback or write-through? write back (It is not consistent with Disk at all times) Write-allocate? yes, because after page fault we bring the page to memory for both writing and reading
There isn't enough information to be sure.
A literal write-through policy would be a performance disaster (imagine having to write 8 KiB to a relatively slow disk every time anything pushed data on the stack). A write back policy would be very bad for fault tolerance (e.g. if there's a power failure you'd lose far too much data).
This alone is enough to imply that it's some kind of custom design (neither strictly write-back nor strictly write-through).
To complicate things more; an OS could take into account "eviction costs". E.g. if the data in memory is already on the disk then the page can be re-used immediately, but if the data in memory has been modified then that page would have to be saved to disk before the memory can be re-used; so if/when the OS needs to evict data from cache to make room (e.g. for more recently used data) it'd be reasonable to prefer evicting an unmodified page (which is cheaper to evict). In addition; for spinning disks, it's common for an OS to optimize disk access to minimize head movement (where the goal is to reduce seek times and improve disk IO performance).
The OS might combine all of these factors when deciding when modified data is written to disk.
Exclusivity/Inclusivity? I think non-inclusive and non exclusive (NINE), maybe because memory mapped files are partially in memory and partially in swap file or ELF file (program text). Forexample stack of process is only in memory except when we run out of memory and send it to a swap file. Am I right?
If RAM is treated as a cache of disk, then the system is an example of single-level store (see https://en.wikipedia.org/wiki/Single-level_store ) and isn't a normal OS (with normal virtual memory - e.g. swap space and file systems). Typically systems that use single-level store are built around the idea of having "persistent objects" and do not have files at all. With this in mind; I don't think it's reasonable to make assumptions that would make sense for a normal operating system (e.g. assume that there are executable files, or that memory mapped files are supported, or that some part of the disk is "swap space" and another part of the disk is not).
However; I would assume that you're right about "non-inclusive and non exclusive (NINE)" - inclusive would be bad for performance (for the same reason write-through would be bad for performance) and exclusive would be very bad for fault tolerance (for the same reason that write-back is bad for fault tolerance).
How are page replacement policies like LRU/LFU implemented ? Does the hardware MMU track the reference count(in case of LFU)?
Is it possible for it to be implemented as part of the kernel?
Generally, the hardware provides minimal support for tracking which pages are accessed, and the OS kernel then uses that to implement some kind of pseudo-LRU paging policy.
Fox example, on x86, the MMU will set the 'A' bit in the PTE (page table entry) whenever a page is accessed. So the kernel continuously loops though all the memory in use, checking, and clearing this bit. Any page that has the bit set has been accessed since the last sweep, and any page where the bit is (still) clear since the last sweep has not. These pages are candidates for replacement. The details vary from OS to OS, but generally there's some sort of queue structure(s) where these pages are tracked, and the oldest ones replaced.
I am trying to understand the number of tables looked-up, when translating a virtual address to a physical address. The Intel manual seems to state numerous schemes:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf
(section 4)
whereas Ulrich Drepper's paper says there are typically 4:
http://www.akkadia.org/drepper/cpumemory.pdf
(page 38)
Whereas I seem to find a lot of diagrams online only showing two:
Could somebody explain which how many page tables are typically accessed on an Intel CPU, or whether it depends on OS configuration (like Huge memory pages etc)?
Short answer
The most commonly used number of page tables on x86-64 system is 4. This is assuming a 64-bit OS using what Intel calls IA-32e paging mode and 4 KB pages. Fewer page tables are needed for some of the other modes (as described in the Intel documentation).
Detailed answer
Figure 4-1 from the Intel 64 and IA-32 Architectures Software Developer’s Manual shows the possible configurations. The columns to focus on are the two address width columns and the page sizes columns. The reason that you see so many different options is because each of these different combinations changes how the pages tables are used and how many are needed.
The most commonly used configuration on x86-64 systems today is the IA-32e paging mode with 4 KB pages and the details for how this works are shown in Figure 4-8.
The value in register CR3 points to the root of the paging structure. There is a 48-bit linear address (the program's virtual address) that needs to be translated to a physical address (with up-to 52 bits). The page offset for a 4 KB page is 12 bits, so that leaves 36-bits in the linear address to index into the page table. The more bits that are used to index into each table structure, the larger that table would need to be. What Intel has done is divide the page table into 4 levels, and each level is accessed with 9 index bits.
If you are using 2 MB pages then you have 21 bits to offset into the page. And so one of the table used in the translation step can be removed, while still keeping the other tables the same size (shown in Figure 4-9).
The other configurations follow the same pattern and you can look in the Intel manual for more detail if necessary.
I suspect that the reason you see diagrams online with only two levels is because that provides enough details to explain the overall concepts used in paging. The additional levels are simply an extension of the same concepts, but tuned for the particular address size and page table size that the architecture wants to support.
It is largely OS dependent. Intel likes to make their processors hyperconfigurable. The number of page table layers is designed to be configurable to handle different physical addresses. For 32-bit addresses (in 32-bit mode) Intel says two levels are normal. For 40-bit addresses, Intel says three levels are normal.
Larger physical addresses => More levels.
Larger pages => Fewer levels
Some non-intel processors take the more rational approach of making the page tables pageable.
Does the Linux on x86-64 support multiple huge page sizes (e.g., both 2MB and 1GB page sizes beyond the 4KB base page size)? If yes, is there a way to specify that for a given allocation which huge page size to use? In other words, my question is if "MAP_HUGETLB" flag is used while doing mmap() it maps them allocation to hugepages of default size. Is there anyway to request an allocation to be mapped on to non-default hugepage size?
Not quite yet, but it's working its way through the LKML. At a guess, the feature will be available in a few releases time.
You will then be able to use the flags MAP_HUGE_2MB and MAP_HUGE_1GB to configure this explicitly.
This image gives a good picture about Virtual Address space. But it only says half of the story. It only gives complete picture of User Address space ie.. lower 50% (or 75% in some cases).
What about the rest 50% (or 25%) which is occupied by the kernel. I know kernel also has so many different things like kernel modules , device drivers, core kernel itself. There must be some kind of layout right?
What is its layout? If you say its Operating System dependent. I would say, there are two major operating systems Windows & Linux. Please give answer for any one these.
alt text http://img690.imageshack.us/img690/2543/virtualadressspace.gif
I've got even worse news for you, there's also a feature to explicitly randomize kernel address layouts by the OS as a security feature. This is on by default in most recent Windows, OpenBSD as well as being an option for Linux.
Like users said here, your picture is incomplete. It tends to look something specific to single-threaded OS. In particular there may be hundreds of threads within the process (hence - sharing the same address space), everyone with its own stack.
Also, I believe the actual picture of the address space may vary strongly depending on OS version and some subtle changes.
It's not completely clear from your question or the image, but with the 'System Address Space' you probably mean the area between 2GB-4GB. This indeed takes up half of the theoretical 4GB space, but there is a valid reason for it.
Normally with 32-bits you can address 4 GB of memory (2^32=4294967296) so it would seem logical to have 4 GB of address space, not 2 GB. The reason for this is the following:
Suppose you have 2 pointers, like this in C/C++:
char *ptr1;
char *ptr2;
I now want to know what the difference is between the two pointers, like this:
offset = ptr2 - ptr1;
What should be the data type of 'offset'?
If we don't know whether ptr1 comes before ptr2 or vice versa, the offset can be positive or negative. Now if both ptr1 or ptr2 are between the range 0 - 2GB, then the offset is always between -2147483648 and +2147483647, which fits exactly in a 4 byte signed integer.
However, if ptr1 and ptr2 would be able to access the full 4 GB address space, offset would be between -4294967296 and +4294967295 which doesn't fit in a 4 byte signed integer anymore.
If you are sure that you are never doing this kind of calculations in your application, or you are sure that if you subtract 2 pointers that they will be never more apart than 2 GB (or your vectors are always smaller than 2 GB), you can tell the linker (Windows, Visual Studio) that your application is LARGEADDRESSAWARE. This linker flag sets a bit in the executable, and if a 32-bit Windows is booted correctly (on XP you had to boot with the /3GB) flag, Windows gave you 3GB instead of 2GB (only for the LARGEADDRESSAWARE executables).
The remaining 1GB is still used for operating system data structures (but I have no details about them).
If you are running a 64-bit Windows, then things get even more interesting, because LARGEADDRESSAWARE executables will then get 4GB of memory. Apparently, the operating system data structures are now stored somewhere in the 64-bit address space, outside the 4GB used by the application.
Hope this clarifies a bit.
Memory Layout of Windows Kernel. Picture taken from Reversing: Secrets of Reverse Engineering
alt text http://img821.imageshack.us/img821/1525/windowskernelmemorylayo.jpg