Talk:Translation lookaside buffer

Security issue

The section about computer security seems misleading to me. How can a rootkit use the TLB in order to hide a program?

For hardware loaded TLBs, the CPU fills the TLB on its own as it is accessing the pagetable (PT). From a programmers point of view, there is no way to alter the content of the TLB as it is not directly accessable (besides from a complete TLB flush).

For software loaded TLBs, the TLB miss handler of the OS is loading PT entries into the TLB. I'm not sure if a rootkit could alter this section of OS code. But even if this was the case and therefore could alter the TLB directly, what would you gain? The process' data structure in the kernel (Process Control Block) is still there and can be read out by a lot of applications (like "top" in linux).

The point here is that hiding a page (or several pages) does not make the process invisible.

GloomY

I was going to say I agreed with GloomY on this, because using the TLB to hide something seemed an unusual claim, but I found an hypothetical rootkit that diverts certain reads on the TLB to different (inaccurate) frames. The theory is that when a program reads memory (via TLB) for comparison against a fingerprint (or whatever method of detection is used), a different page frame is returned, making the rootkit invisible to this detection mechanism.

This information found in this Blackhat presentation.

-- Pyrofysh 06:14, 4 June 2006 (UTC)

Ambiguity in overview

In the first paragraph, the sentence "The buffer is typically a content-addressable memory (CAM) in which the search key is the virtual address and the search result is a real or physical address (which is often not the same thing)" could confuse a newcomer since there are 2 possible interpretations:

• A) (the correct interpretation) virtual addresses and physical addresses are almost never the same

• B) (incorrect interpretation) "physical" addresses and "real" addresses are not the same thing.

To correct this, it could just say, "...and the search result is a physical address (which is often not the same thing."

Clock Cycle Statistics

At the end of the article, the equation that gives the average number of cycles on a TLB access seems flawed. I feel it should be the following, since even a TLB miss will require a TLB access (hence will take 1 + 30 cycles):-

$1\times 0.99+(30+1)\times 0.01=1.30$

-Anjul Patney

Nowhere in that section did it say that a TLB access takes 1 clock cycle. It said "If a TLB hit takes 1 clock cycle, a miss takes 30 clock cycles...", so a TLB hit takes 1 clock cycle and a TLB miss takes 30, not 31, cycles. Maybe a TLB access takes 1 clock cycle regardless of whether it gets a hit or a miss, and handling the miss takes an additional 29 clock cycles. Guy Harris (talk) 23:44, 26 July 2011 (UTC)

IIRC in the x86/x86-64 for example, in cr3 is stored physical address hence no TLB access is needed. I am not sure why could it stored virtual address as to resolve any address it would need to look up the page table. But to find page table it would need to find page table which would end in non-terminating loop. Uzytkownik (talk) 20:36, 26 July 2011 (UTC)

A TLB hit or miss requires a TLB access if for no other reason than to see whether you got a hit or a miss.... Guy Harris (talk) 23:44, 26 July 2011 (UTC)

"It was the first cache introduced in processors."

There is a note that citation is needed. In "Intel386 TM DX MICROPROCESSOR 32-BIT CHMOS MICROPROCESSOR WITH INTEGRATED MEMORY MANAGEMENT" (www.digchip.com/datasheets/parts/datasheet/227/386DX-pdf.php chapter "4.5.4 Translation Lookaside Buffer" page 55) there is a little bit about it: TLB is the one and only internal cache memory. I don't know if that's enought so can someone verify it ?

--Kicer86 (talk) 08:21, 1 August 2010 (UTC)

!!! This is total bullshit. Many years before i386 there was motorola MC68010 with instruction cache. --dramenbejs

And before that there were, e.g., the 8-word associative TLB cache on the IBM System/360 Model 67 and a CPU cache on the IBM System/360#models|System/360 Model 85. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:08, 11 December 2013 (UTC)

ITLB and DTLB

Can somebody explain what they are and the differences between them?

"Page-table" vs. "page table".

The article currently refers to "page-table entries", "page-directory entries", and "page-fault handlers", with the most recent edit saying that MOS:HYPHEN applies.

That section of the Manual of Style says:

To link related terms in compound modifiers:

and, in that subsection, says:

A hyphen can help to disambiguate (little-celebrated paintings is not a reference to little paintings; a government-monitoring program is a program that monitors the government, whereas a government monitoring program is a government program that monitors something else).

English compound#Hyphenated compound modifiers, to which the first quote refers, says

If, however, there is no risk of ambiguities, it may be written without a hyphen: Sunday morning walk.

and this is a case where there is no risk of ambiguity. "Page", in "page table", is a noun adjunct, not an adjective; parsing "page table entry", with "page" and "table" separately modifying "entry", makes no sense. Guy Harris (talk) 05:37, 6 January 2018 (UTC)

Intel use both forms - "page table entry" and "page-table entry" - in the third volume of the the x86 reference, as does AMD in the second volume of the AMD64 reference. IBM uses only "page table entry" in the Power ISA 3.0B reference, although they use both forms in version 11 of the z/Architecture reference. At least as of the last version I downloaded, the ARMv8-A reference uses only "page table entry" (trying to get documentation from ARM is like pulling teeth - you need an account, they now require two-factor authentication to log in to download a manual, and they seem to get permanently stuck when I send them the access code from the email they send). So the industry doesn't seem to unanimously think the hyphen is necessary. Guy Harris (talk) 20:38, 6 January 2018 (UTC)

Notes

Physical memory vs physical address

It is not correct to say TLB "stores [...] translations of virtual memory to physical memory" as stated in the overview. The translation is from virtual memory to physical addresses, which could be device addresses mapped into a host's address space. From Memory-mapped_I/O, we know that "a memory address may refer to either a portion of physical RAM, or instead to memory and registers of the I/O device". References to "physical memory" should probably be corrected to "physical address".

Should TLB Shootdown Be Mentioned in The Performance Section?

TLB Shootdown is when a process makes a call to the OS to unmap memory. The OS then has to not just remove the entry in the page table and clear the TLB on the current core but also has to send an Inter-processor interrupt to clear the TLB entries in other cores. This is because that process might have multiple threads on different cores and have used the memory in the range to be umapped or even if running on a sinigle thread, may have run on different cores. This can have quite a performance hit because sending that interrupt and then waiting for the other cores to finish their TLB clear can take a while TB5ivVaO1y55FkAogw1X (talk) 21:54, 25 December 2023 (UTC)