5

I am trying to understand how the physical addresses are allocated when running an OS.

My question is when the kernel allocates some memory (lets say using kmalloc), who decides what physical memory address range should be mapped for this virtual memory range?

I understand that kernel will create page tables to translate the mapping from virtual to physical and the MMU will use it. But before that, someone should allocate/assign some physical pages to be mapped. Is this done by the kernel itself or will the MMU let the kernel know a particular range of physical addresses that can be used?

If the kernel itself assigns the physical addresses, how does it keep track of what physical addresses are already used and what are free (to be used)?

1
  • In addition to the other answers, if you have a system with multiple NUMA (Non-Uniform Memory Access) memory nodes, then the NUMA Memory Policy can be used to control which NUMA memory node(s) a memory allocation is made from which is something a user space process can control. Aug 1 at 6:22

2 Answers 2

8

I am trying to understand how the physical addresses are allocated when running an OS.

Physical addresses are not allocated, they're already there – it's the RAM.

My question is when the kernel allocates some memory (lets say using kmalloc), who decides what physical memory address range should be mapped for this virtual memory range?

Who: the kernel memory mapping algorithm. So, the kernel.

But before that, someone should allocate/assign some physical pages to be mapped.

As said, the physical memory is the reality that the kernel has to deal with.

The question of how the memory chips are mapped to form a piece-wise contiguous memory range depends on your hardware and its boot process. In desktop or server x86, typically, as you initialize the DRAM controller during boot, firmware (or your bootloader) reads the contents of the DRAM memory modules ("DIMMs") "configuration EEPROM"s and configures the memory controller of your CPU (or the mainboard, depending on the specifics of your hardware) to translate memory address accesses to read and writes for these chips accordingly. On embedded platforms, the RAM configuration might just be baked into the software (e.g., uboot and the Linux kernel initializing hardware using devicetree) and then the memory controller gets configured that way.

So, there's no universal answer here. "How to deal with dynamic memory" is one of the main things that architectures differ in – and that can get pretty detailed and CPU-model-specific, if you remember PAE on i386.

who decides what physical memory address range should be mapped for this virtual memory range?

Let's talk about how: since the kernel, through hardware or firmware interfaces, or through configuration files, knows how much physical memory is where in the physical address space, where the memory mapped IO is, and what memory it's already using, it is able to keep a data structure tracking free physical memory. So, when you call kmalloc with a specific size, you look for an unused piece of physical memory that fits the size requirement.

1
  • 1
    "Physical addresses are not allocated, they're already there" You seem to be interpreting "allocate" as "create". Allocation means assigning the address to a particular use.
    – Barmar
    Aug 1 at 15:05
1

It's simple.

  • Initially, as part of the boot process, the CPU resets the MMU.
  • The kernel detects the physical memory (RAM), and builds data structures that kmalloc can allocate. The RAM where the kernel's code lives is excluded.
  • When the kernel decides to run a process (/sbin/init) initially, it allocates needed internal tables, and a block of RAM to map in the executable.
  • Only then, as part of process srartup, the MMU is set, using "page tables" so every process sees a memory space beginning at location 0, and this process's location 0 is unique. Every process's location 0 is toxic - you'll get a SEGV - segment violation if you use it. This detects uninitialized pointers.
  • While the CPU is in 'supervisor' mode (a hardware state) the MMU is disabled. The MMU takes effect when the kernel transfers control to the process, and clears 'supervisor' mode.
  • Now active, the MMU inserts itself into the CPU<->RAM hardware path, so it's now CPU<->MMU<->RAM.
  • Every address issued by the CPU has its high order bits replaced with bits from the page table, until the CPU gets back into 'supervisor' mode, via an interrupt.
6
  • 3
    On which architectures is the MMU disabled in supervisor mode? Jul 31 at 19:21
  • If the MMU was disabled in supervisor mode, KASLR would be impossible… Jul 31 at 19:22
  • @MarcusMüller My bad. I was symplifying, and decided to omit the kernel's use of MMU. My 'supervisor' mode MMU off remark holds. KASLR: Kernel Address Space Layout Randomization
    – waltinator
    Jul 31 at 19:55
  • @StephenKitt It's specified in the CPU manual. Any modern CPU has a way to move between "Protection/Capability Rings". In ring 0 (Least Protection, Highest Capabilities) the CPU has complete control of all, including the MMU. The idea of loading page tables into an active Memory Management Unit should make your head spin. Without an MMU, every task sees the same memory addresses, and multitasking becomes Very Difficult. BTDT (Been There, Done That).
    – waltinator
    Jul 31 at 20:09
  • 4
    But the MMU isn’t disabled in supervisor mode. It’s possible to make it transparent, but it’s never disabled. As Marcus says, the kernel relies on it in supervisor mode... Jul 31 at 20:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .