2. Fórumok
  3. Processzorok, tuning
  4. Új AMD processzorok a jövő év első felében
Keresés

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

  • #68 Ayg0 senior tag Thrawn #67
    Új Válasz #68
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Ayg0

    senior tag

    válasz Thrawn #67 üzenetére

    Több féle környezetben tesztelték az egyik X3-mat: tömörítés, videó- és zenekodolás, játékok, tervezés stb. Pl játékok közt volt a Colin 4, ami ha jól emlékszem anno a Ti elemzésetekben is szerepelt, mint 4 magot (is) kezelő program. És sok másikkal egyetemben ebben a "meccsben" is alul maradt egy Athlon X2 4600+ -szal szemben.

    *mod: most néztem, hogy nem X3 volt, hanem X4 9100e ami talán még rosszabb...

  • #63 Raymond titán Thrawn #60
    Új Válasz #63
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Raymond

    titán

    válasz Thrawn #60 üzenetére

    Azt a BIOS-t nem fogod latni. Update: [link]

    A lenyeg:

    "The "AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS" document is a SPEC CLARIFICATION, and is simply a pointer to a previous document written in April 2007.
    SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel® Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch."

    Tehat a piacon nincs fix nelkuli termek.

  • #61 P.H. senior tag Thrawn #60
    Új Válasz #61
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

  • #52 P.H. senior tag Thrawn #29
    Új Válasz #52
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

  • #31 Oliverda titán Thrawn #29
    Új Válasz #31
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Oliverda

    titán

    válasz Thrawn #29 üzenetére

    Nézegettem én is azt a doksit. ;)

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

Hirdetés