Memory page - virtual or physical and relation to data types allocation?

Question

I'm looking for a understandable definition of memory pages. Please help me clarify the following questions:

• Is a "memory page" always related only to a data chunk of virtual memory?
• Are physical RAM addresses also split into pages?
• How does a definition of a "memory page" as the smallest unit of data for memory management in a virtual memory operating system fit into the fact that it's possible to allocate a chardata type which is usually one byte (compared to 4Kb of usual page size)?

Answer 1

Is a "memory page" always related only to a data chunk of virtual memory?

In some sense. The kernel has pages internally used for DMA, I/O buffering, block and inode cacheing, etc. These are all physical memory pages, but they're not visible as such to any user process unless they're mmapped.

Are physical RAM addresses also split into pages?

Yes - the two have to be equivalent for paging to work sanely

[paraphrase] is a page really the smallest unit if you can allocate a char

A page is the smallest unit the kernel VM system deals in. User processes request memory from the kernel in whole pages.

Your userspace process will then have an internal mechanism for managing objects allocated inside these pages.

Note that even if you think you allocated one char, you didn't - the allocator will add some overhead to track the allocated block.

Note also that this discussion about sub-page allocators also applies inside the kernel (in the parts that are using, rather than managing, memory).

The reasons the kernel doesn't deal in smaller units are:

1. they're inefficient for pagefile purposes (anything smaller than a disk block is going to be wasteful in practice), and

2. each allocation incurs some fixed management overhead - the smaller the block, the more memory you need to reserve for tracking lots of little objects.

   Your 1-char allocation example likely has 4-8 bytes of management overhead; if you're allocating lots of these, perhaps only 1/9th of your memory is actually useful (equivalently, your memory use just increased by a factor of 9 for a given amount of data). The same 8-bytes for a 4Kb page represent a pretty low overhead.

Answer 2

Pages are the chunks of memory that may be swapped between RAM and the hard disk in order to support virtual memory.

Example: Say you have 1 MB pages, 2 MB of physical RAM, and a lot more virtual RAM. You run application A that takes 1 MB. It gets one virtual page of memory, which is mapped to one of the physical pages. Then you run application B that requires 2 MB. Application B's memory will be spread across two virtual pages. When we start executing application B, we either have to move application A's page onto disk so we can have both of B's pages in RAM, or we have to swap between B's two pages constantly as we run it. Hopefully that's enough to get the idea across.

So the direct answers to your questions are:

• Yes. A page of physical RAM always corresponds to a page of virtual RAM. Virtual addresses are what your programs actually operate on, so any physical address that did not map to a virtual one would be completely inaccessible to applications (including the OS, I think).

• Yes, paging is a mapping of physical memory chunks to virtual memory chunks, so physical addresses are definitely involved.

• That phrase is referring only to the OS code that handles the implementation of virtual memory (i.e., the page swapping). It is not referring to the OS code that allocates memory for you.