What's The Advantage of 3G/1G Vm Split ? 32Bit Linux Kernel

What's the advantage of 3G/1G vm split ? 32bit linux kernel

The TLB also includes a supervisor flag that indicates if the mapping can be used by regular processes or if it is only usable when a process is running with the supervisor flag set -- i.e., when the process is executing in kernel context.

This supervisor flag allows the TLB to be useful for both the process (it doesn't automatically get privileges to the data in the kernel's gigabyte) and allows the kernel to have complete access to all the process's memory when executing in kernel mode.

This means a process can enter and exit kernel mode without incurring TLB flush penalties.

If the memory was not split (say, the 4:4 patch giving four gigabytes to userspace and four gigabytes to kernel space is in use) then the TLB must be flushed on every kernel enter / exit to map either the privileged space or the userspace and all data being copied into and out of the kernel must go through tedious remapping mechanisms.

Why kernels make use of the high logical address

Before PIC (Position-independent code) was popular, there are lots of static linked programs can only be loaded at specified address, likely 0x400000

To be able to compatible with these programs, the kernel must not obtain the address space. So the kernel is located at high 1G address space.

How does the linux kernel manage less than 1GB physical memory?

Not all virtual (linear) addresses must be mapped to anything. If the code accesses unmapped page, the page fault is risen.

The physical page can be mapped to several virtual addresses simultaneously.

In the 4 GB virtual memory there are 2 sections: 0x0... 0xbfffffff - is process virtual memory and 0xc0000000 .. 0xffffffff is a kernel virtual memory.

  • How can the kernel map 896 MB from only 512 MB ?

It maps up to 896 MB. So, if you have only 512, there will be only 512 MB mapped.

If your physical memory is in 0x00000000 to 0x20000000, it will be mapped for direct kernel access to virtual addresses 0xC0000000 to 0xE0000000 (linear mapping).

  • What about user mode processes in this situation?

Phys memory for user processes will be mapped (not sequentially but rather random page-to-page mapping) to virtual addresses 0x0 .... 0xc0000000. This mapping will be the second mapping for pages from 0..896MB. The pages will be taken from free page lists.

  • Where are user mode processes in phys RAM?

Anywhere.

  • Every article explains only the situation, when you've installed 4 GB of memory and the

No. Every article explains how 4 Gb of virtual address space is mapped. The size of virtual memory is always 4 GB (for 32-bit machine without memory extensions like PAE/PSE/etc for x86)

As stated in 8.1.3. Memory Zones of the book Linux Kernel Development by Robert Love (I use third edition), there are several zones of physical memory:

  • ZONE_DMA - Contains page frames of memory below 16 MB
  • ZONE_NORMAL - Contains page frames of memory at and above 16 MB and below 896 MB
  • ZONE_HIGHMEM - Contains page frames of memory at and above 896 MB

So, if you have 512 MB, your ZONE_HIGHMEM will be empty, and ZONE_NORMAL will have 496 MB of physical memory mapped.

Also, take a look to 2.5.5.2. Final kernel Page Table when RAM size is less than 896 MB section of the book. It is about case, when you have less memory than 896 MB.

Also, for ARM there is some description of virtual memory layout: http://www.mjmwired.net/kernel/Documentation/arm/memory.txt

The line 63 PAGE_OFFSET high_memory-1 is the direct mapped part of memory

MMU implementation

TLB in Intel architecture is handled in the hardware. This paper from intel references the TLB implementation.

why do_anonymous_page() call pte_unmap() just after set a new pte entry?(linux kerenl 2.6.11 memory management)

If you read how the page_table was populated in the first place you will see it was pte_offset_map-ed first. It should be no surprise that there is a matching pte_unmap.

The page_table thingy IS NOT the pte thingy which is set here.

Rather, on certain architectures the kernel has a very limited address space. For instance i386 is able to address 4GB of memory. This is typically split into 3GB for userspace and 1GB for kernel. But all kernel memory typically does not fit into 1GB. Thus the problem is combated by temporarily mapping and unmapping various pages where possible, as needed. page tables of userspace processes, as can be seen, are subject to this behaviour. These macros don't map/unmap anything on amd64, which has big enough address space for the kernel to permanently map all physical memory.

MMU implementation

TLB in Intel architecture is handled in the hardware. This paper from intel references the TLB implementation.

Do kernel code and data get cached in the CPU caches?

The CPU does not know what a kernel is. It just applies the translations as it always does. The kernel is (almost) not concerned with CPU caches either.

CPU caches cache by physical location. All of that is transparent to any software that runs (except if the software explicitly breaks the abstraction by asking the hardware some question about caches and such).

The kernel uses virtual addresses.

Caching kernel code and data is very important. In some BIOSes you can disable the CPU cache. When you do that booting takes hours. Even if the kernel just takes 1% of the CPU time that time would be magnified to be 99%.



Related Topics



Leave a reply



Submit