By: TREZA (no.delete@this.ema.il), August 22, 2013 5:30 pm
Room: Moderated Discussions
Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on August 22, 2013 4:52 pm wrote:
> rwessel (robertwessel.delete@this.yahoo.com) on August 20, 2013 12:08 am wrote:
> > Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on August 19, 2013 3:28 pm wrote:
> > >
> > > Thanks, this reply definitely clears up quite a few loose ends!
> > >
> > > - So to my understanding, this "special register" simply lists the physical address of the base
> > > of the array of the process currently being worked on. Correct? (I assume the physical address of
> > > the base would be needed so that things can be "scaled" from the beginning of the array up?)
> >
> >
> > Typically the special register (CR3 on x86, for example) simply contains the physical address of the root
> > of the page table structure. On x86 that's the first entry
> > of the page directory. In the illustration above
> > (for x86 in 32-bit, non-PAE mode), the page directory contains
> > 1024, four byte, entries. Each of those entries
> > can be marked invalid, in which case the 4MB region they
> > would map is not valid, or is marked valid, in which
> > case the PDE points to a page table, which also has 1024, four byte, entries, each one valid or invalid.
> > Valid ones contain a translation to a physical page address, the invalid ones don't.
> >
> >
> > > - You definitely gave quite an informative chunk about page tables; but I don't believe I figured
> > > out the answer to one of my questions: If the LSU compares the TLB entries to the first line of the
> > > L1 cache and does NOT find a match; where does it go from there? Does it go to main memory and use
> > > the page tables to locate the needed information, or does it scale from L1 to L2 to L3, etc.?
> >
> >
> > The LSU does not compare TLB entries to anything. After the TLB is used to translate a virtual address
> > to a physical address, the physical address is used to look up the requested cache line in the L1 cache.
> > If it's not there, the (same) physical address is used to check the L2, then the L3, L4 (if present),
> > etc., and ultimately main memory. After the translation happens (once), it doesn't happen again.
>
> Thanks and sorry for the late replies; I don't mean to make it a habit, work
> has just been eating up a lot of my time as the summer comes to a close.
>
> - So the "first entry" of the root of the page table can be variable depending on what addresses
> are invalid, yes? So if entries 1-61 are invalid, then the route would be 62, and the special
> register would keep this physical address documented in the special registers; yes?
>
> - I mean to say in the case that there is a TLB miss. In that
> case, would it scale up chronologically? L1 to L2 to L3, etc?
>
> Thank you very much for your time! I think I'm starting to hone in on
> the end of the very fundamentals of the concepts you're teaching me.
>
Page tables are indexed by bits in the virtual address. Different architectures have different levels of page tables and selections.
Example: SPARC32 :
bits VA[31:24] identifies one of 256 entries in the first level table. Each entry can be either a valid mapping for a 16M area, a pointer to the L2 table or invalidated.
bits VA[23:18] identifies one of 64 entries in the second level table. mapping for a 256kB area, a pointer to the L3 table or invalidated.
bits VA[17:12] identifies one of 64 entries in the third level table. mapping for a single 4kB page or invalid.
bits VA[11:0] are not modified by the MMU.
(there are also contexts, but this is another story...)
The whole address space don't need to be entirely mapped down to each 4kB page, large areas can be covered by high level mappings.
To give a perspective on page tables sizes, often a 32bits word is used to map a 4kB area, which means that the page tables occupy around 1/1000 of the managed memory.
"Invalid" means that any access triggers a trap to the operating system which then decides whether it is a bug (out of bounds accesses, null pointers...), or, instead, that the memory was copied to disk, or never initialised... In that case the OS corrects the situation then resumes execution of the application software.
[I'm not sure these explanations could help, though !]
> rwessel (robertwessel.delete@this.yahoo.com) on August 20, 2013 12:08 am wrote:
> > Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on August 19, 2013 3:28 pm wrote:
> > >
> > > Thanks, this reply definitely clears up quite a few loose ends!
> > >
> > > - So to my understanding, this "special register" simply lists the physical address of the base
> > > of the array of the process currently being worked on. Correct? (I assume the physical address of
> > > the base would be needed so that things can be "scaled" from the beginning of the array up?)
> >
> >
> > Typically the special register (CR3 on x86, for example) simply contains the physical address of the root
> > of the page table structure. On x86 that's the first entry
> > of the page directory. In the illustration above
> > (for x86 in 32-bit, non-PAE mode), the page directory contains
> > 1024, four byte, entries. Each of those entries
> > can be marked invalid, in which case the 4MB region they
> > would map is not valid, or is marked valid, in which
> > case the PDE points to a page table, which also has 1024, four byte, entries, each one valid or invalid.
> > Valid ones contain a translation to a physical page address, the invalid ones don't.
> >
> >
> > > - You definitely gave quite an informative chunk about page tables; but I don't believe I figured
> > > out the answer to one of my questions: If the LSU compares the TLB entries to the first line of the
> > > L1 cache and does NOT find a match; where does it go from there? Does it go to main memory and use
> > > the page tables to locate the needed information, or does it scale from L1 to L2 to L3, etc.?
> >
> >
> > The LSU does not compare TLB entries to anything. After the TLB is used to translate a virtual address
> > to a physical address, the physical address is used to look up the requested cache line in the L1 cache.
> > If it's not there, the (same) physical address is used to check the L2, then the L3, L4 (if present),
> > etc., and ultimately main memory. After the translation happens (once), it doesn't happen again.
>
> Thanks and sorry for the late replies; I don't mean to make it a habit, work
> has just been eating up a lot of my time as the summer comes to a close.
>
> - So the "first entry" of the root of the page table can be variable depending on what addresses
> are invalid, yes? So if entries 1-61 are invalid, then the route would be 62, and the special
> register would keep this physical address documented in the special registers; yes?
>
> - I mean to say in the case that there is a TLB miss. In that
> case, would it scale up chronologically? L1 to L2 to L3, etc?
>
> Thank you very much for your time! I think I'm starting to hone in on
> the end of the very fundamentals of the concepts you're teaching me.
>
Page tables are indexed by bits in the virtual address. Different architectures have different levels of page tables and selections.
Example: SPARC32 :
bits VA[31:24] identifies one of 256 entries in the first level table. Each entry can be either a valid mapping for a 16M area, a pointer to the L2 table or invalidated.
bits VA[23:18] identifies one of 64 entries in the second level table. mapping for a 256kB area, a pointer to the L3 table or invalidated.
bits VA[17:12] identifies one of 64 entries in the third level table. mapping for a single 4kB page or invalid.
bits VA[11:0] are not modified by the MMU.
(there are also contexts, but this is another story...)
The whole address space don't need to be entirely mapped down to each 4kB page, large areas can be covered by high level mappings.
To give a perspective on page tables sizes, often a 32bits word is used to map a 4kB area, which means that the page tables occupy around 1/1000 of the managed memory.
"Invalid" means that any access triggers a trap to the operating system which then decides whether it is a bug (out of bounds accesses, null pointers...), or, instead, that the memory was copied to disk, or never initialised... In that case the OS corrects the situation then resumes execution of the application software.
[I'm not sure these explanations could help, though !]
