Talk:Page table

From Wikipedia, the free encyclopedia

Former FA This article is a former featured article candidate. Please view its sub-page to see why the nomination did not succeed. For older candidates, please check the Wikipedia:Featured article candidates/Archived nominations.

Contents

[edit] Physical adresses?

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)

[edit] 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)

[edit] 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!

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)

[edit] 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)

[edit] 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?

[edit] 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)

[edit] 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.