1

I was reading up on a rather-dated article on the kernel managing memory and had this question on where the Page Table Entries (PTE) would go into.

For this example, the author assumes we are on a 32-bit machine with 4GB memory without PAE. The article assumes 3GB to be addressable as virtual memory (4KB pages of 3GB == 786,432 pages). But if there was a PTE of 4 bytes for each page, that in itself would account for ~3.1MB of memory which should be set aside by the kernel. Is this going to be a part of kernel memory? ie. kernel reserved memory apart from the user addressable 3GB?

So, does the kernel first calculate and arrive at how much kernel (system) memory would be needed and how much it can mark as user-addressable memory at boot?

What other stuff would reside in kernel/system-reserved memory?

4
  • You realize that "user-addressable" is on a per-process basis, right?
    – Ignacio Vazquez-Abrams
    Nov 24, 2013 at 10:31
  • So, the kernel just starts off with the minimum required system-reserved memory at first and this can grow? Similarly, as and when processes need to start (be it from a startup script or manually), the kernel calculates and assigns virtual addresses to the processes if they would fit? Of course, all this is just from theory, I've never looked at the actual kernel code.
    – Optimized Coder
    Nov 24, 2013 at 10:43
  • 1
    1) As Ignacio points out, virtual address space is per process. 2) Virtual address space is not memory. It's address space -- the actual memory it requires is more or less just the PTE's, I believe, and probably not all of that exists initially. Address space which is actually accessed and used must be mapped to real memory, but few processes ever use much of the addresses allocated to them. en.wikipedia.org/wiki/Virtual_address_space "Address space" = the map. "Memory" = the territory. But the former isn't really there until a process looks for it. Then it's allocated.
    – goldilocks
    Nov 24, 2013 at 10:55
  • If the difference between actual memory and address space isn't really clear to you, stop and work that out, ask questions, etc. It's fundamental and if you don't get it, can be very confusing. Short answer to your question: the kernel doesn't set any memory aside. It just creates a map of what could be -- but this could be is (most likely) way more than what is really physically available.
    – goldilocks
    Nov 24, 2013 at 10:56

1 Answer 1

Reset to default
0

Typically, on x86 without no PAE, there will be a user/kernel split of 3Gb/1Gb. This means that the top 1Gb of memory are reserved for the kernel, while user space accesses memory at the lower 3Gb. This is done this way to avoid having to update the register that points to page tables (CR3) and flush the TLB every time there is a context switch. With this optimization, CR3 is updated and the TLB is flushed only when scheduling a different process.

The information about how virtual addresses should be interpreted is stored in three places:

  • Virtual Memory Areas (aka VMAs, aka mappings): these associate a contiguous memory region to a backing store (either a file, or swap, for anonymous mappings.
  • Page table entries: these asscociate a whole page of virtual addresses to the corresponding physical addresses, and contains permissions and misc flags. PTEs are loaded lazily from the VMAs: a PTE won't necessarily be instantiated (and the corresponding page paged in: this is paging-on-demand) until an access is attempted; only processes that access the 3GB of memory will need 3Mb of page tables.
  • The TLB: this is a HW cache of the page table.

You must log in to answer this question.

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