How Does One Determine the Page Frame Number for Device Memory

How does one determine the page frame number for device memory?

The specific example you've provided is implementing a character device file that allows one to map physical memory, very similar to /dev/mem. By specifying the offset of the file you specify the physical memory address. Hence the calculation that takes the offset and divide in the page size to find the PFN.

For a "real" device driver, you would normally have the physical address of the device memory mapped registers or RAM hard coded from the device specification, and use that to derive the PFN (by dividing by the page size).

Determining frame size and other calculations in a paging system

a) How many frames does the system memory contain?

Number of frames= Physical Address space / frame size

            = 512MB / 16KB
= 2^29 /2^14
= 2^15
= 32K frames

b) How many bits does the system use to maintain displacements (i.e offsets), and how many bits does the system use to maintain page numbers?"

Number of pages= Logical address space / page size

           = 2 ^48 / 2^14
= 2 ^ 34
= 16G pages.

Number of bits for page number=34

Number of bits for offset= 14 bits i.e. (48-34)

is number of frame = number of pages(linux)?

Physical pages are called page frames (you can call them frames). The term page is reserved for pages in virtual memory.

The virtual memory is divided into chunks of equal size by the kernel. Physical memory is also divided into pages (page frames) of the same size.

For example if we have 4GB of RAM, on 32 bits architecture, this means : 1048576 page frames of size 4KB

Let's continue,

for each page frame (physical page) the kernel maintain a structure struct page. This structure is defined in linux/mm_types.h(, this structure contain a member named mapping (struct address_space *mapping) which specifies the address space in which a page frame is located. There also a member named index which represent the offset inside this mapping.

All struct pages are kept in global mem_map array this array is used by the kernel to know all the associations between virtual and physical memory.

Finally, to convert a virtual address to a physical one the kernel use the macro virt_to_page() defined in asm-i386/page.h which point to pfn_to_page(

Before an example, let's see the layout of an address in 32 bits architecture

| 10 bits - Directory | 10 bits - Page table | 12 bits - Offset |

Let's see an example of translating memory virtual address to physical one:

Hope this help.


How to calculate page frames in a 16 bit address pointer

  1. A 16bit address bus allows to access 2^16 = 64kB of physical memory. Since on this system you have pages of size 1024B = 2^10, your memory falls into 2^16 / 2^10 = 2^6 physical frames.

  2. Given the previous result, with pages of 1024 = 2^10 bytes, you need 10 bits for accessing any bytes of the page. Thus, the 6 high-order bits ares used for getting the page index from the page table (basically the figure 1 in your homework), and the 10 low-order bits are used for offsetting in that page.

  3. The logical address 0xfce resides in the fourth page because the six high-order bits are 000011b = 3 = 4th page = 0x0c00-0x0fff. Given the page table and assuming the physical memory is sequential, the fourth page maps to the sixth physical frame which start at 1024 * 6 = 0x1800 = 0001100000000000b. The six high-order bits of the page are 000110b, where we add the 10 bits of offset resulting from the previous answer: 000110b << 10 | 0x3ce = 0x1bce.

  4. Since the frame allocation is not sequential (4, 6, 8, 9), the hole between pages 4 and 6 (i.e. 1024B), and the hole between page 6 and 8(i.e. again 1024B), result in physical memory fragmentation.

Hope this help.

Can someone explain this about paging in operating system?

That text isn't very clear admittedly. I'll try to clear it out.

When translating a virtual address into a physical one, a fixed number of lower bits don't get translated:

| High bits | Low bits |
| |
| |
V |
[Page tables] |
| |
| |
| Physical address |

The lower bits number is tied to the page size: if we assume 4KiB pages then the lower 12 bits are fixed and not translated.

We also assume that the virtual address space is 32 bits.

If a page table entry is 32-bit long it can give 32 bits to use as the high part of the physical address.

Thus we have 20 (32 - 12) bits in input and 32 bits in output when looking up the page tables.

With the additional 12 bits from the fixed part this gives 32 + 12 = 44 bits of physical address.

An updated figure:

        <---------- 32 bits ----------->
<---- 20 bit -------> <- 12 b ->
| High bits | Low bits |
| |
| 20 bit |
V |
[Page tables] |
| |
| 32 bit |
| Physical address |
<-------- 32 bits ---------> <- 12 b ->
<------------- 44 bits --------------->

This is not a true 44-bit addressing however, pointers are still 32-bit.

Application can only access 4GiB of memory directly, but the OS can map an
application to the first 4GiB, another to the second 4GiB and so on.

This is similar to how PAE works on x86.

The assumption that all of a page table entry is used to give the higher bits of the physical address is untrue.

Some of the bits are used to set the attribute of the frame: cache-ability, access right, mapping status and so on.

The higher bits of the physical address are called page frames.

The number of page frames is determined by the structure of a page table entry, not by the size of the virtual address space (nor of the physical address space).

If a page table entry has 50-bit for the frame number then there are 250 frames.

The lower part of the physical address is called page offset and it is determined by the page size (or frame size, they are equal by design).

Related Topics

Leave a reply