OSDev.org

What is the purpose of using an LDT? Could one not just have a GDT with all the needed entries? (null, ring 0 flat code and data, ring 3 flat code and data, tss)

Would it be correct term-wise to say that a page is virtual, and is mapped to a page frame, which is physical, and thus when allocating physical memory one allocates page frames?

The LDT subdivides a GDT Segment, it allows the Kernel to create sub-segments specific to each process (as well as call gates and such), you do not need an LDT and they are rarely used.

Without knowing the exact meaning of your terms, "page frame" is taken as a physical page, which would be correct.

Hi,

Rogator wrote:What is the purpose of using an LDT? Could one not just have a GDT with all the needed entries? (null, ring 0 flat code and data, ring 3 flat code and data, tss)

IMHO the LDT was meant for environments that use segmentation. The idea being that you use the GDT for things that are used by all software (e.g. the kernel's segments) and an LDT for each process. For example, you could have an OS where the LDT is changed every task switch and processes allocate
segments of memory, rather than pages of memory.

Most OS's don't use segmentation though, so the LDT isn't used. It would be possible to use a single LDT for all software, which is something I've done before - the GDT was mostly used for TSS's (hardware task switching) and the LDT was used for code segments (with flat 4 GB data segments).

Rogator wrote:Would it be correct term-wise to say that a page is virtual, and is mapped to a page frame, which is physical, and thus when allocating physical memory one allocates page frames?

I'd say there's physical pages which exist in the physical address space, and virtual pages which exist in the virtual/linear address space. A virtual page might be associated with a physical page, but it might be associated with part of the swap space, or part of a memory mapped file or something else (or nothing for allocation on demand).

IMHO you couldn't say "a page is virtual, and is mapped to a page frame" because the page is a physical page before it's mapped into the page frame. Something like "a physical page is mapped into a page frame to become a virtual page" would be more correct. Also physical pages are used for page frames, but there isn't a one-to-one relationship - you don't have a page frame for each page allocated.

Also it's possible (although much less common and it does depend on the OS's design) for physical memory to be allocated for other purposes (not virtual memory). This could include page tables and page directories, but could also include other data structures used only by the kernel when paging is disabled. For example, you could have an OS where the kernel uses the first 4 MB of each virtual address space, and disables paging to access additional data (so that processes can use 4092 Mb of virtual memory).

Anyway, I'd rewrite the above as:

A physical page is mapped into a page frame to become a virtual page, and thus when allocating physical memory to be used for virtual memory one may need to allocate additional physical pages to be used as page frames.

I can be fairly pedantic at times though, and it'd depend what this sentence was to be used for...


Cheers,

Brendan

I was always under the impression that physical pages and page frames are exactly the same thing. After all, you don't really map a physical page into a page frame -- the mapping is just there. A page frame is defined by its frame number, which is really its physical address, minus the low bits which all must be zero -- same as a physical page. So what does a frame have that a physical page doesn't have, and vice-versa?

but there isn't a one-to-one relationship - you don't have a page frame for each page allocated.

But if you don't have a page frame for an allocated page, then that allocated page must be a virtual page that is not resident in physical memory. I don't see how this makes frames different from physical pages...

Hi,

Colonel Kernel wrote:I was always under the impression that physical pages and page frames are exactly the same thing. After all, you don't really map a physical page into a page frame -- the mapping is just there. A page frame is defined by its frame number, which is really its physical address, minus the low bits which all must be zero -- same as a physical page. So what does a frame have that a physical page doesn't have, and vice-versa?

I was always under the impression that "page frame" meant page table or the "frame" that held the references to pages (if "page frame" was the same as "page" people wouldn't bother writing it).

After some research it seems I'm wrong. The term "page frame" is used in systems where the CPU can't access all memory, and chunks of memory are mapped into the CPUs (physical) address space. On top of this "mapping chunks of memory into the physical address space" these systems can have paging (similar to 80x86 paging).

For example, the CPU would use the linear address and page tables to find a physical address, and then ask for data at that physical address. External hardware (memory controller) would associate pages of memory to page frames (or physical memory areas). This is much like the old "expanded memory" used in 80x86 before extended memory and 32 bit addressing came along, where banks of RAM (64 Kb each AFAIK) were switched into the CPU's physical address space.

Therefore "page frames" don't exist on 80x86 anymore (unless you want to count banked switched video modes). I'm not sure which architectures do use page frames though...

In light of this I'd like to change my former attempt into:

"A physical page is mapped into a page table to become a virtual page, and thus when allocating physical memory to be used for virtual memory one may need to allocate additional physical pages to be used as page tables."


Cheers,

Brendan

I'll have to dig through my old OS textbooks then... I'm not familiar with your other definition of "frame" either... what CPU architectures use the term in that sense?

FWIW, NT's memory manager has a "page frame database" that tracks the current status of each physical page, and each resident virtual page has a corresponding PFN (page frame number).

On page 320 of "Operating Systems: Design and Implementation, 2nd Ed.", Tanenbaum says:

The virtual address space is divided up into units called pages. The corresponding units in the physical memory are called page frames. The pages and page frames are always exactly the same size.

On page 270 of "Operating Systems, 2nd Ed.", Stallings says:

Suppose, however, that main memory is partitioned into equal fixed-size chunks that are relatively small and that each process is also divided into small fixed-size chunks of the same size. Then the chunks of a process, known as pages, can be assigned to available chunks of memory, known as frames, or page frames.

Hi,

Colonel Kernel wrote: I'll have to dig through my old OS textbooks then... I'm not familiar with your other definition of "frame" either... what CPU architectures use the term in that sense?

It seems to be limited to the old 80x86 expanded memory and 8-bit/16-bit embedded systems.

I guess if a computer doesn't support any form of bank switching then a "page frame" would refer to a physical page of memory that is always the same RAM (rather than an area in the physical address space that can be mapped to different areas of RAM).


Cheers,

Brendan

Using the word "frames" for physical memory and "pages" for virtual memory is (I believe) the traditional way to make a difference between those. Some sources use "frames/pages", and some use "physical/virtual pages". The former is used more in academic circles, while the latter seems to be more popular recently. It's the same thing.

In any case, "frames" more or less always refers to page-sized units of physical memory in a virtual memory system.