will the HW update the TLB when I modify a page table entry?

will the HW update the TLB when I modify a page table entry?

Reply to
dick
Loading thread data ...

You'll get better answers if you mention what HW you're using.

Reply to
Arlet Ottens

No, you have to use an instruction to invalidate the TLB entry. Page tables can be quite large, so it is impossible to monitor writes to page tables.

Wilco

Reply to
Wilco Dijkstra

I think, it is not possible. But, i wonder if there is any such design in existence ?

Karthik Balaguru

Reply to
karthikbalaguru

s
Reply to
dick

TLB is a one-way cache. Don't mix it with data cache. So: No write back. BTW: Even with data-cache: invalidate will not write back, because the data it contains is _invalid_.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

So if I want to implement a LRU replacement, how can I check the dirty bit and reference bit? how can I flush the TLB entries back to the page table before I check these bits?

Reply to
dick

On the PPC (I have done it for the G2/603e core) you do not implement the LRU replacement for TLBs, it is implemented in hardware. Whenever you load a new TLB the least recently used one will be discarded to make space for your new load, you cannot control that. I suppose you could maintain a parallel TLB array in software and do on it what you expect the MMU to do, although I see no point in doing that (nor is there a way to guarantee coherency between the two other than never making the wrong guess). Again, the TLB cache is not a write-back one, it does never write anything anywhere, you can only write to it. On the PPC mentioned above, that is. And you just do not have access to the dirty, referenced etc. bits in the TLB cache (nor in any other cache on that core, actually).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

un, 13 Jan 2008 20:19:25 -0800 (PST), dick

Reply to
Didi

what I said was "LRU page replacement".

When CPU changes a word, the page table entry will indicate this page is dirty and referenced. but we have TLB, the dirty and reference bits are in TLB cache now. how can SW check the dirty and reference bits?

Reply to
dick

Oh that's another thing. You maintain a complete page translation table by software; you do maintain all the bits per PTE (page translation entry) by software, you deal with them in the ISI/DSI exception handlers. Depending on the device, you get all the info you need in some special purpose registers - this is how it works on the PPC I have used, at least. When you get an instruction or data translation miss exception, you locate the respective PTE; depending on what you find in it, you either just load a new TLB cache entry and return (i.e. you had the page translated and it was not a first write to it etc.), or you handle things further - e.g. if this is the first reference to this page you run (simulate in the G2) an ISI or DSI exception, which deals with the situation essentially referring to the PTE table, which is in memory. Once you have prepared the right PTE, you either load it in the TLB or exit and leave it to the repeated translation miss exception to find the now usable for it entry.

Which page and when you write to disk or recover from disk has nothing to do with the TLB cache, you do that in the ISI/DSI exception handlers (i.e. working on/with your memory based PTE table). How you maintain which entry was least recently used, which is swapped and has to be brought back etc. is your call as far as the processor is concerned.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

Just mark a page as inaccessible and the page faults will tell you.

Wilco

Reply to
Wilco Dijkstra

too bad.

so periodically I have to invalidate the whole TLB, mark all page table entries as inaccessible but keep the information in other place. then page fault occur, the handler finds out which page causes the exception, and set that page table enty back to accessible state, then load the entry into TLB. then set the page table entry's referenced and dirty bits to 1s

is it correct?

Reply to
dick

Correct. It is how all paging OSes work. Normally they don't do it for all pages in one go (this would give a large performance hit), but for a subset of pages. In particular the OS first picks a set of pages to be recycled based on usage history, marks them as inaccessible, and places them in a page-out buffer for a while before reusing them (after writing to disk if dirty). If those pages are used while waiting they are made available immediately and some other candiates are picked for paging. So as a result of paging activity one gets the usage info of pages for free.

You really want to read a good book on OS design.

Wilco

Reply to
Wilco Dijkstra

Thank you.

Can you recommend some books about OS implement?

Reply to
dick

At Uni we used Structured Computer Architecture by Tanenbaum, but there are several newer and more specific books by him: Operating Systems Design and Implementation and Modern Operating Systems.

Wilco

Reply to
Wilco Dijkstra

Another vote to professor Tanenbaum.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.