Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.arch    |    Apparently more than just beeps & boops    |    131,241 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 130,975 of 131,241    |
|    MitchAlsup to All    |
|    Re: Inverted Page Tables / Background TL    |
|    05 Feb 26 02:14:12    |
   
   From: user5857@newsgrouper.org.invalid   
      
   scott@slp53.sl.home (Scott Lurndal) posted:   
      
   > MitchAlsup writes:   
   > >Robert Finch posted:   
   > >   
   >   
   >    
   > >> The Linux docs   
   > >> refer to flushing the TLB I think as a synonym for invalidating the TLB.   
   > >> Is there a difference? When one says 'flush' I think of writing out   
   > >> entries back to memory. For instance the accessed and modified flags bits.   
   > >   
   > >I do not know of any TLB that has a TLB state equivalent   
   > >to MODIFED (like a normal DCache); so when used and modified TLB entries   
   > >are migrated back to DRAM immediately, there is no need to flush--there   
   > >may be need to invalidate from TLB while maintaining a PTE in the tables   
   > >themselves.   
   > >   
   >   
   > How do you handle hardware access and/or dirty flag updates? If you   
   > store that in the TLB entry, it will need to be written back to   
   > the page table in DRAM at some point; either at the time of transition   
   > or when the TLB entry is evicted.   
      
   A message* is sent to DRAM when used or modified gets set--maybe even   
   a few cycles before TLB u/m gets over-written.   
      
   (*) message uses a special interconnect OpCode and carries modified PTE(s),   
   so other TLBs may play along without watching everything on the 'bus'.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca