Keresés

Új hozzászólás Aktív témák

  • P.H.

    senior tag

    válasz Thrawn #60 üzenetére

    Ahogy mondod: sosem, legfejlebb következtetni lehet. Az Intel-nél egy-egy (akármilyen szintű) TLB-bejegyzés módosításhoz ez a szekvencia biztonságos:

    In a multi-processor system, when one processor changes a page table or page directory entry, the changes must also be propagated to all other processors. This process is commonly referred to as “TLB shootdown.” The propagation of changes to page table or page directory entries can be done using memory-based semaphores and/or interprocessor interrupts (IPI).
    For example, the following describes a simple TLB shootdown sequence for an Intel 64 or IA-32 processor:

    1.Begin barrier — Stop all but one processor; that is, cause all but one to HALT or stop in a spin loop.
    2.Let the active processor change the necessary PTEs and/or PDEs.
    3.Let all processors invalidate the PTEs and PDEs modified in their TLBs.
    4.End barrier — Resume all processors; resume general processing.

    AMD-nél pedig K8 óta van Flush Filter:

    The TLB's can be seen as caches containing the translation information stored in the address translation tables in memory. The actual translation requires several levels of indirections through the tables stored in main memory. This is the so-called "table walk"
    A very time consuming process which may take many hundreds of cycles for a single TLB entry. The Opteron attempts to speed up the table walk with a 24 entry Page Descriptor Cache.
    Even so, it remains important to avoid the table walk whenever possible in a multi-tasking multi-threaded environment. A table walk becomes necessary whenever entries in the TLB do not correspond to the memory resident translations anymore because somebody has modified the latter.

    Until now there was only one way to guarantee TLB coherency: Flush the TLB's if it may be possible that any of the entries is not identical anymore to the memory resident tables. Many actions in the x86 architecture result in an automatic flush of the TLB's, often unnecessary. A new feature in the Opteron: The TLB flush filter can avoid these costly flushing in many occasions.
    The TLB Flush filter is implemented as a 32 entry, Content Addressable Memory (CAM). It remembers the addresses of regions in memory that were accessed when the TLB's were loaded. These regions thus belong to the Page Translation Tables. The Filter then keeps monitoring all accesses to memory to see if any of these regions are accessed again. If not then it may disable the flushing of the TLB's because coherency is guaranteed.

    Valahol itt lehet az AMD-processzorok jó virtualizációs teljesítményének kulcsa. De sokáig nem lehet növelni a TLB- és cache-méreteket úgy, hogy minden memóriahozzáférést el kell juttatni az L1-ekhez, az L2-khöz, a TLB-khez és az L3-hoz.

  • P.H.

    senior tag

    válasz TK36 #58 üzenetére

    "Felülméretezni" cache-t csak kétféleképpen lehetne, a TLB-k vagy a cache-ekre nehezedő nyomás miatt, amúgy L1/L2/L3 relációban is a minélnagyobb/minélnagyobb/minélnagyobb szabály érvényes.

    Egyrészt pl. a Core2 TLB-megközelítés nem optimális, mégis működik:

    "One of the stark differences between Nehalem and the Core 2 TLBs is the degree to which they cover the caches. In Core 2, there was 6MB of cache and the TLBs could translate 2176KB of memory using the smaller 4KB pages (most applications do not use large pages), effectively covering half or a third of the full L2 cache (depending on whether we are discussing Merom or Penryn). In contrast, each Nehalem core has 576 entries for the small pages and 2304 for the whole chip. This many TLB entries can translate 9216KB – more than enough to contain the whole 8MB L3 cache using small pages alone." ([link]).

    Másrész végletekig fokozni mind az exclusive, mind az inclusive cache-felépítést csökkentheti a hatékonyságot: az inclusive (Intel) és az exclusive (AMD) felépítésnél is később be kell vezetni, hogy egy shared last level cache-hez csak bizonyos számú mag tartozik.

    A TLB-k sebességkritikussága (1 órajel) miatt szerintem ez fognak határt szabni először a cache-ek növekedésének (de itt már inkább a x86 világon kívülről fognak példákat venni a mérnökök).

  • P.H.

    senior tag

    válasz Thrawn #29 üzenetére

    SZVSZ a fudzilla cikke valóban hype most: az a szakasz, amit említ a Specification Update doksiban, szóról szóra megegyezően megtalálható a Merom és a Penryn dokumentációinak végén is (bár előbbi 2008 májusi, abban is az "Intel will update the Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide in the coming months." mondat szerepel, amit meg is tettek jó ideje, a "Propagation Of Page Table And Page Directory Entry Changes To Multiple Processors" fejezet hozzáadásával.

    A hiba a Merom dokumentációban AI91, a Penryn-ében AW48 jelzéssel jelenik meg. A Nehalem Spec. Update doksiban a hiba a következőképpen szerepel:

    AAJ69. An Unexpected Page Fault or EPT Violation May Occur Following the Unmapping and Re-mapping of a Page
    Problem: An unexpected page fault (#PF) or EPT violation may occur for a page under the following conditions:
    • The paging structures initially specify a valid translation for the page.
    • Software modifies the paging structures so that there is no valid translation for the
    page (e.g., by clearing to 0 the present bit in one of the paging-structure entries
    used to translate the page).

    • Software later modifies the paging structures so that the translation is again a valid
    translation for the page (e.g., by setting to 1 the bit that was cleared earlier).

    • There is a subsequent load from a linear address on the page.
    • Software did not invalidate TLB entries for the page between the first modification
    of the paging structures and the load from the linear address.

    A három hibából, amit felsoroltál, kettő a C6 power state-hez köthető, és ha azt nézem, hogy további 10 hiba is miatta van, valószínűleg az első verziókban ez nincs engedélyezve (vagy nem teljes mértékben).
    A "Writes to IA32_CR_PAT or IA32_EFER MSR May Cause an Incorrect ITLB Translation" már érdekesebb, mert azokat virtualizálás esetén minden world switch-nél (host»guest és guest»host) írni kell (az IA32_EFER pár bitje van csak használva, de ebben van az NX bit globális használatának engedélyezése és a 32-64 bites üzemmódok váltása is ennek írásával valósul meg; az IA32_CR_PAT pedig OS-függően tartalmazza, hogy mely lapok cache-elhetők és milyen módon (uncached, write-back, write-combining, stb), ráadásul nem specified, hanem certain körülmények között jön elő. Valószínűleg a jelenlegi BIOS workaround kiküszöböli, viszont a virtualizációs teljesítményre negatív hatással lehet.

Új hozzászólás Aktív témák