Talk:Page table

Physical adresses?

It should be noted that the reference given here for Inverted Page Table is confusing the concept with a Hashed Inverted Page Tables and Hashed Page Tables... references for this complaint can be found: http://www.cs.jhu.edu/~yairamir/cs418/os5/sld037.htm , http://cs.uttyler.edu/Faculty/Rainwater/COSC3355/Animations/invertedpagetable.htm , http://www.eecs.berkeley.edu/~kamil/teaching/sp04/040104.pdf , "Schaum's Outline of Principles of Computer Science" , "Computer architecture and implementation" By Harvey G. Cragon , . There, in the least, should be made a distinction between linear Inverted Page Tables (which is the basic reference implementation) and hashed Inverted Page Tables (which is a combination of the speed improvement of Hashed Page Tables and the Inverted Page Table scheme)... Considering that the entry would be confusing for anyone unaware of this issue. —Preceding unsigned comment added by 152.14.243.172 (talk) 22:13, 10 March 2010 (UTC)

Shouldn't the inverted page table (which is basically a hashmap mapping from keys (virtual address) to values (physical address)) also contain the physical address in each entry? Because we apply a hash to the virtual address plus we can even have collisions, the obtained physical address can't be just the table index that we are regarding, right? That also implies that the term "inverted page table" (which suggests that it is simply a table indexed by the physical address and containing the virtual addresses) is misleading, although it is the standard name for this construct. Yogi de 10:53, 4 Jan 2005 (UTC)

I don't think so (I could be wrong, but this is my understanding). We get a virtual address that we feed through the hash anchor table to get a candidate page frame number. If the virtual address in the entry indexed by the candidate page frame number is the same as our virtual address, we can simply use that page frame number to refill the TLB. If the match fails however, we follow the collision chain and repeat until it is exhausted, on which we fault.

The beauty of this is that the virtual address is comprised of two parts, (in a 32-bit arch) a 16-bit virtual page number and a 16-bit offset, which are merely smooshed together to get a virtual address. When we get the page frame number, we simply use that instead of the virtual page number, and we keep the offset. Smooshing them together, we get a valid, physical, linear address. Dysprosia 11:34, 4 Jan 2005 (UTC)

But your "page frame number" is the (part of the) physical address that I said was missing. So far the article just says For each row there is an entry for the virtual address, other data, and a means for creating a collision. It should make clear that this "other data" includes the physical address. Of course when I say "physical address" I mean only the page frame number as that has been translated - just like you only mean the virtual page number when you say "virtual address" in the article. But the way it is phrased in the article, it sounds as if that physical page number wasn't present. Then you would know that you have the right entry (via the virtual address), but wouldn't have the associated data that you wanted to look up (namely the physical page frame number). I think the sentence in the article should be rephrased to: For each row there is an entry for the virtual and corresponding physical page frame number, other data, and a means for creating a collision. By the way, what do you mean with means for creating a collision? Do you mean collision detection? Yogi de 12:08, 5 Jan 2005 (UTC)

The IPT is indexed by the physical page frame number, so the page frame number isn't actually part of the entry. I'll take a look at the wording on the collision chain in the article now. Dysprosia 12:39, 5 Jan 2005 (UTC)

It sure is misleading, but that's marketing for you. The so-called "inverted page table" is best viewed as an off-chip extension of the TLB. Unlike a true page table, it does not hold information about all the pages. Like the software-filled TLB of traditional MIPS, the OS has to help out every now and then. AlbertCahalan 05:59, 3 February 2006 (UTC)

Combine Extended Page Table into this

I just copied the relevant portions from Extended Page Table into this article under the section 'page table types'. Please feel free to reject the change if I have changed too early. —Preceding unsigned comment added by 207.46.55.29 (talk) 10:27, 24 September 2010 (UTC)

Combine with virtual memory

It seems to me that this page should be combined with the virtual memory page, or at the very least, a significant amount of material moved to that page.

Consider, in particular, the pictures at the start of the two articles. They are almost identical (although the Page table picture is nicer). It's clear that much of the same ground is covered in both places.

One possible way to factor the two articles would be to have the virtual memory article talk about the uses and policies of virtual memory, and leave the page table article to talk about the various actual implementations of page tables. Unfortunately, that means the virtual memory article is going to end up being the FA candidate, and the page table article will be more technical and less accessible.

Iain McClatchie 00:08, 19 October 2005 (UTC)

It's because of the nonsense that is the FAC process at the moment seems to favour nominators to somehow fully understand the subject at hand. Perhaps in desperation to get an actual technical article featured (gasp!) I bloated the article unnecessarily. I agree that a nice balance needs to be struck between the VM and the page table article. Maybe I'll even do it if I get a chance ;) Dysprosia 09:44, 19 October 2005 (UTC)

Dead link

During several automated bot runs the following external link was found to be unavailable. Please check if the link is in fact down and fix or remove it in that case!

• http://cne.gmu.edu/modules/vm/purple/ptable.html
  • In Page table on Mon Jul 17 15:16:06 2006, 404 Not Found
  • In Page table on Thu Jul 27 00:43:23 2006, 404 Not Found

---

maru (talk) contribs 04:43, 27 July 2006 (UTC)

That page now redirects to http://cs.gmu.edu/cne/modules/vm/purple/ptable.html. I've updated the article accordingly. Cheers, CWC(talk) 13:05, 5 September 2006 (UTC)

Something missing?

Say we have a computer architecture where the word size is 32 bits. This means we are able to form addresses from 0x00000000 to 0xffffffff - spanning 4GB.

Something is wrong or at least missing here. I would rather rewrite the sentence the following way.

Say we have a computer architecture with a 32 bit address bus. This means we are able to form addresses from 0x00000000 to 0xffffffff - spanning 4 Gi individual addresses, or 4 GiB when a single address contains 1 Byte.

I hope I'm correct. --Abdull 19:00, 20 November 2006 (UTC)

I agree with you, this should be fixed. Asymmetric (talk) 11:16, 8 January 2008 (UTC)

wrong offset example?

the page offset 0xbabe that you're using in the discussion is not a correct offset, as they are limited to 4KB

am I correct?

Address translation illustrated for x86

I made some drawings illustrating the address translation for x86 compatible processors. Perhaps you can use it for your article(s). :-)

• 
• 
• 
• 

--84.72.190.27 (talk) 12:01, 20 March 2008 (UTC) (RokerHRO)

Examples of Usefulness

Under the types of page tables someone should clarify why one system would be advantageous over another. For example under multilayered page table the following sentence may clarify why it is useful:
If we are working a a 32-bit address space with 4 KB per page then it is conceivable that any process could use up to 1 million individual pages. To store this information would require a contiguous 1 million pages to index into, which can be hard to come across. A multilayered page table solves this problem.
I'm not sure about inverted page tables or virtual ones.

Why virtual addressing

Virtual addressing is also an important solution to external fragmentation, am I right? Speedarius (talk) 03:05, 9 November 2008 (UTC)

Article Bloated

I agree that the article is bloated. After the opening description, the next 7 sections are about what memory is, what it's used for, virtual memory etc. All of these topics have articles of their own, and it is not neccessary to duplicate them here. I suggest these sections be removed and links to these topics be provided instead. I certainly gained nothing from these 7 sections, except annoyance that I had to skip past them in order to find out about the actual topic I had come here to read about.

I also find the tone of the piece too conversational. Far too many sentences start with 'Say you...', which is fine when describing a concept to someone in person, but I don't think is acceptable in an authorative article.Gechurch (talk) 12:27, 7 December 2008 (UTC)

I agree with both of you. This article should strictly be about the Page Table. Also what's with under the diagram? It says, "Not all pages are in physical memory, here.". That doesn't make any sense, should be reworded. —Preceding unsigned comment added by 72.136.214.96 (talk) 00:33, 25 December 2008 (UTC)

I have removed the first 7 sections so now the first section is 'Role of the page table'. I have also reworded the first half of this section. I believe it is much more accessible now, but I have removed some technical detail which arguably should stay. In particular I have removed the break-up of virtual addresses. I personally would like to see a one-sentence explanation of pages and frames, as parts of the article rely on this as prior knowledge. I will do this later (I've been looking at the article too long now and it's all a blur).

I would like to see the new structure stay. It is a major rework though, and it shows. I think the article needs more rewording and would love to see peoples edits/suggestions.

I believe the caption is simply trying to say that the diagram has virtual addresses that are not in physical RAM (ie. are in the pagefile) and therefore are not shown. I have made a minor edit to this effect. Gechurch (talk) 10:47, 26 December 2008 (UTC)

Thanks for fixing it, the article is much more on focus now. —Preceding unsigned comment added by 72.136.214.96 (talk) 23:28, 26 December 2008 (UTC)

Page Fault Exception For TLB Miss?

I have read somewhere that the MMU will trigger a PF after not finding the page in the page table lookup, not after a TLB miss. As far as I understood it, after a TLB miss the MMU will go to the page table to look it up, and only after a miss there will trigger a PF. This is not what the text here says. Anyone wants to confirm or deny this? —Preceding unsigned comment added by 93.173.172.11 (talk) 19:53, 24 April 2009 (UTC)

This article is not a general description of address translation. Certainly there are processor architectures that do far more address translation in hardware, without falling back so frequently on OS (kernal) intervention. See, for example, descriptions of the IBM 370 (1970s era -- yes, TLBs are older than Intel and Microsoft!) or "ESA/390 Principles of Operation" at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar008/CCONTENTS. A TLB miss on mainframes did not cause an interrupt, just hardware-managed table lookups. Evaluist (talk) 15:33, 8 May 2009 (UTC)

As for modern processors, well at least on x86, TLB misses do not cause a page fault. The TLB is completely transparent to the system programmer. Check out the section on Exception #14 (page fault) in the Intel Software Developer's manual. TLB misses are not mentioned. A TLB miss just means that the processor will have to do memory translation the slow way: walk the page table and do all the memory lookups. 70.225.168.145 (talk) 17:25, 18 June 2009 (UTC)

The original poster is right. The page fault occurs when the page does not reside in main memory. TLB miss simply means that the page table entry in question needs to be found through the slower-path, by walking the page table. A finer point here, though, is that the page table structure itself can be paged out, in which case a page fault would occur as part of servicing the TLB miss. Either way, the distinction is clear. TLB miss does not automatically trigger a page fault.

Merge Extended Page Table article with this article

I suggest we merge the Extended Page Table article with this article. --BwB (talk) 20:22, 29 July 2009 (UTC)

 Not done per discussion on Talk:Extended Page Table; no consensus for merge. --KarlB (talk) 03:45, 1 July 2012 (UTC)

Yes. This article isn't about the x86 MMU, it's about page tables in general. Discussing the general concept of a machine's VM support allowing a guest to directly manipulate its own page tables without trapping to the VM monitor might belong here, but specific details of one particular processor family's VM support, not so much (maybe if it covered, for example, support for it in multiple architectures, e.g. S/3x0 and x86). Guy Harris (talk) 06:55, 1 July 2012 (UTC)

Frame

Perhaps "frame" should be defined? —Preceding unsigned comment added by 99.255.57.120 (talk) 01:12, 22 October 2009 (UTC)

I agree. The term is used without explanation or hyperlinking and is completely unclear. If I knew what was intended, I'd fix it instead of complaining here. Hiiiiiiiiiiiiiiiiiiiii (talk) 05:25, 18 June 2011 (UTC)

How big?

How big is a typical page table in relation to the TLB and where is it typically stored? Presumably it's stored in RAM in some special place that can be accessed without reference to itself. Perhaps an expert in the field could add this information. 49.145.132.39 (talk) 09:35, 9 January 2018 (UTC)

"How big is a typical page table in relation to the TLB"? For traditional multilevel page tables (as opposed to inverted page tables), significantly bigger, but the size depends on the size of the address space the page table is mapping and how many pages are present in main memory (if a broad range of addresses is paged out or otherwise not in memory, instead of a large number of individual page table entries marked "not present", the higher-level page table entries can, at least with some memory management units, be marked "not present"). Inverted page tables, as the section of page table pointed to earlier indicates, are typically some fraction of the size of main memory.

"where is it typically stored?" Somewhere in main memory. Whether the operating system reserves a particular region of physical memory for page tables, or just uses the same pool of page frames that it uses for paged-in pages, depends on the operating system; I suspect most just use the same pool of pages.

"Presumably it's stored in RAM in some special place that can be accessed without reference to itself." That doesn't require a special place. For a multilevel page table, there's typically a machine register that contains the physical address, rather than the virtual address, of the top-level item in the page table. That item contains a number of entries that point to items below it; those pointers also contain physical, rather than virtual, addresses. The bottommost items point to pages themselves, again giving the physical address. As those addresses are all physical addresses rather than virtual addresses, they can be used directly, and don't have to be translated using the page table. Guy Harris (talk) 10:01, 9 January 2018 (UTC)

another dead link

The AMD manual link is dead. I'm not sure if some of these others from amd site cover the same topic:
http://support.amd.com/TechDocs/24592.pdf#search=AMD64%20Architecture%20Software%20Developer%27s%20Manual
http://support.amd.com/TechDocs/24593.pdf#search=AMD64%20Architecture%20Software%20Developer%27s%20Manual
http://support.amd.com/TechDocs/24594.pdf#search=AMD64%20Architecture%20Software%20Developer%27s%20Manual
Hoemaco (talk) 09:34, 3 February 2018 (UTC)

The AMD manual link was added in this edit on 28 March 2006. The URL that was linked was saved in the Wayback Machine on March 22, 2006 and on April 22, 2006; in neither case was there a manual called the "AMD64 Architecture Software Developer's Manual" listed on that page. Perhaps the editor mistakenly thought the "AMD64 Architecture Programmer's Manual" was called the "AMD64 Architecture Software Developer's Manual"; apparently, it wasn't.

The links you give are for volumes of the "AMD64 Architecture Programmer’s Manual"; here's the AMD page that currently points to them, although it also points to a lot of other stuff.

But the only place I see in the article that would need that reference is the "Nested page tables" section, which refers to Intel 64-specific and AMD64-specific features. The rest of the article, except for the last sentence of the "Inverted page table" section, is talking about page tables in general, not about specific instruction set architectures. So there should probably be references to the specific volumes of the Intel and AMD manuals attached to the last sentence of "Nested page tables", rather than items in "Further reading", unless we give links to similar manuals for other instruction sets in "Further reading". Guy Harris (talk) 12:03, 3 February 2018 (UTC)