Pada mikroprosesor dengan manajemen TLB perangkat keras (katakanlah Intel x86-64) jika miss TLB terjadi dan prosesor sedang berjalan di halaman tabel, apakah ini (off-chip) memori mengakses melalui hirarki cache (L1, L2, dll. )?
Tidak ada hubungannya dengan desain elektronik. Pertanyaan akan ditutup.
Leon Heller
8
Ia bertanya bagaimana chip tertentu bekerja, jadi saya pikir itu pada topik.
Olin Lathrop
5
@ OlinLathrop: Saya setuju: Saya pikir detail level rendah dari sirkuit terintegrasi sesuai topik.
davidcary
Saya harus setuju, jika tidak ada yang lain, men-debug fungsi prosesor kami adalah langkah utama untuk mendapatkan desain sistem deterministik yang baik. Ini semakin dekat dengan salah satu batas kita, tetapi tampaknya kuat di dalam.
Kortuk
Jawaban:
8
Ya, sejauh yang saya tahu, pada prosesor Intel x86-64, ketika miss TLB terjadi dan prosesor sedang berjalan di halaman tabel, akses memori off-chip melewati hierarki cache.
Saya masih sedikit kabur pada beberapa detail, dan saya harap jawaban lain akan mengisinya - bukankah ada manual Intel atau AMD yang menggambarkan halaman berjalan dalam detail yang luar biasa? Pemahaman saya adalah:
Alamat virtual dalam beberapa register alamat pertama-tama diserahkan ke TLB cepat untuk dikonversikan ke alamat fisik - alamat dalam PC diserahkan ke L1 ITLB, alamat dalam register lain apa pun diserahkan ke L1 DTLB .
Jika pencarian pertama gagal, ada tingkat TLB yang lebih lambat dan lebih besar yang dicoba. (Apakah L2 TLB ini dipecah menjadi ITLB dan DTLB juga, atau apakah itu cache TLB yang disatukan? Apakah ada level TLB lebih lanjut - L3? L4?)
Jika pencarian TLB sepenuhnya gagal, dan walker VHPT x86 dan x86-64 dinonaktifkan, CPU memberi sinyal kesalahan TLB, yang dicegat oleh kernel OS. Pemahaman saya adalah bahwa hampir semua CPU non-x86 melakukan hal yang sama - menangani TLB sepenuhnya dalam perangkat lunak. Jika diaktifkan, prosesor x86 dan x86-64 memiliki table walker VHPT berbantuan perangkat keras yang menangani beberapa langkah berikutnya. (Apakah chip x86 dan x86-64 memiliki satu bit yang sepenuhnya menonaktifkan VHPT, atau ada banyak bit yang dapat mengaktifkan VHPT untuk beberapa rentang alamat dan menonaktifkan VHPT untuk rentang alamat lainnya? Di mana bit-bit itu berada?)
jika pencarian TLB benar-benar gagal, alamat virtual asli (mungkin mode pengguna) V1 dikonversi ke V2, alamat virtual dari entri tabel halaman PTE yang menyimpan nomor halaman fisik untuk V1.
Karena V2 sekali lagi merupakan alamat virtual, CPU melewati terjemahan alamat virtual-ke-fisik yang normal, kecuali ia melewatkan L1 dan langsung ke L2.
Perangkat keras mencari alamat virtual V2 di TLB secara paralel dengan mengambil PTE itu dari cache L2 (hampir diindeks).
Karena V2 bukan alamat instruksi, itu tidak melalui cache instruksi L1; dan karena V2 bukan alamat data pengguna normal, ia tidak melalui cache data L1. V2 awalnya dimasukkan ke dalam cache L2 terpadu (instruksi terpadu + data + cache PTE). Lihat "contoh hierarki cache" .
Jika cache L2 (atau L3 atau cache lain yang diindeks secara virtual) berisi PTE, maka VHPT mengambil PTE dari memori cache dan menginstal PTE untuk V1 di TLB, dan alamat fisik di PTE yang digunakan untuk menerjemahkan alamat virtual asli V1 ke dalam alamat RAM fisik, akhirnya mengambil data atau instruksi sepenuhnya dalam perangkat keras tanpa bantuan dari OS.
Jika semua level cache yang diindeks secara virtual gagal, tetapi pencarian TLB kedua ini berhasil untuk V2, maka VHPT mengambil PTE dari cache yang diindeks secara fisik atau dari memori utama, menginstal PTE untuk V1 di TLB, dan alamat fisik di dalamnya. PTE digunakan untuk menerjemahkan alamat virtual asli V1 ke dalam alamat RAM fisik, yang pada akhirnya mengambil data atau instruksi sepenuhnya dalam perangkat keras tanpa bantuan dari OS.
Jika pencarian TLB kedua ini gagal, walker VHPT hardware menyerah dengan VHPT TRANSLATION FAULT.
Ketika VHPT TRANSLATION FAULT terjadi, CPU terperangkap ke OS. OS harus mencari tahu apa yang salah dan memperbaiki:
(a) mungkin halaman yang berisi V2 saat ini ditukar dengan disk, sehingga OS membacanya ke dalam RAM dan memulai kembali instruksi yang gagal, atau
(B) mungkin program kereta mencoba membaca atau menulis atau mengeksekusi beberapa lokasi yang tidak valid, dan OS menghentikan proses, atau
(c) berbagai trik lain yang dilakukan penulis OS untuk menggunakan mekanisme ini untuk menjebak berbagai jenis akses - muat halaman yang berisi V1 yang dapat ditukar dengan disk; berbagai jebakan yang digunakan untuk men-debug program baru; untuk mensimulasikan "W ^ X" pada CPU yang tidak secara langsung mendukungnya; untuk mendukung copy-on-write; dll.
Diagram di halaman 2 dari Thomas W. Barr, Alan L. Cox, Scott Rixner.
"Caching Terjemahan: Lewati, Jangan Berjalan (Tabel Halaman)"
yang menarik garis antara "Entri yang disimpan oleh cache MMU" dan "entri yang disimpan oleh cache data L2". (Ini mungkin makalah yang berguna bagi orang yang mendesain CPU baru , yang benar-benar sesuai topik untuk "Desain elektronik").
Saya suka jawabannya, tetapi saya mungkin salah satu dari banyak yang tidak memiliki keahlian yang dibutuhkan untuk merasa nyaman memberikan apa yang mungkin patut mendapat pujian. Sebagai ahli lain memverifikasi saya akan memberikan perwakilan yang sudah Anda dapatkan.
Kortuk
Saya tidak percaya ini benar. Bullet 1 + 2 tentang pencarian TLB adalah AFAICT yang benar, tetapi 3 tidak. Tabel berjalan di x86 (atau x86-64) tidak ditangani dalam perangkat lunak (pengecualian berlaku, lihat nanti) tetapi dalam perangkat keras. Yaitu ketika CPU menentukan tidak dapat menyelesaikan alamat menggunakan TLB, itu sendiri akan berjalan tabel halaman mulai dari tabel yang ditunjukkan oleh register CR3. Hanya jika resolusi ini tidak berhasil maka ia akan memanggil penangan kesalahan halaman CPU. Pengecualian adalah ekstensi virtualisasi di mana dalam mode tertentu hypervisor akan menyelesaikan kesalahan halaman yang terjadi pada tamu.
Morty
Saya tidak berpikir x86 memiliki cara untuk melakukan pembaruan perangkat lunak TLB. ISA yang memungkinkan penanganan TLB lunak memiliki instruksi khusus untuk SW untuk memodifikasi entri TLB, tapi saya rasa x86 tidak memilikinya, selain invlpguntuk membatalkan caching TLB apa pun untuk addr tambahan yang diberikan. Jika trotoar HW tidak menemukan entri untuk alamat virtual itu, atau izin entri tidak memungkinkan akses, Anda mendapatkan #PFpengecualian. OS menangani itu dengan memperbarui tabel halaman (mungkin setelah paging dalam data dari disk, atau melakukan copy-on-write), dan kemudian melanjutkan sehingga load / store yang bermasalah akan kembali berjalan dan trotoar HW akan berhasil.
Saya cenderung setuju bahwa ini termasuk dalam stackexchange arsitektur komputer, bukan stackexchange elektronik, tetapi karena ini ada di sini:
@davidcary benar.
Beberapa sejarah:
Intel x86 page table walks TIDAK di-cache hingga P5, alias Pentium. Lebih tepatnya, akses memory table table walk tidak di-cache, melewati cache. Karena sebagian besar mesin hingga saat itu adalah write-through, mereka menerima nilai yang konsisten dengan cache. Tapi mereka tidak mengintip cache.
P6, alias Pentium Pro, dan AFAIK semua pemroses tabel berjalan selanjutnya diizinkan untuk mengakses cache, dan menggunakan nilai yang ditarik dari cache. Jadi, mereka bekerja dengan cache write-back. (Tentu saja Anda dapat menempatkan tabel halaman dalam memori yang tidak dapat dipadamkan, didefinisikan, misalnya oleh MTRR. Tapi itu adalah kerugian kinerja yang besar, meskipun dapat berguna untuk debugging OS.)
By the way, ini "mengakses tabel berjalan memori dapat mengakses cache data" terpisah dari "entri tabel halaman dapat disimpan (di-cache) dalam TLB Ttranslation Lookaside Buffer)." Pada beberapa mesin, TLB disebut "Terjemahan Cache".
Masalah terkait lainnya adalah bahwa interior node dari tabel halaman mungkin di-cache dalam lebih banyak lagi struktur data mirip TLB, misalnya cache PDE.
Satu perbedaan utama: cache data adalah koheren, dan diintip. Tetapi cache TLB dan PDE tidak diintip, yaitu tidak koheren. Intinya adalah bahwa, karena tabel halaman mungkin di-cache dalam TLB dan koheran PDE yang tidak koheren, dll, perangkat lunak harus secara eksplisit menyiram entri individual atau grup massal (seperti, seluruh TLB), ketika entri tabel halaman yang mungkin sudah begitu cache diubah. Setidaknya ketika diubah dengan cara "berbahaya", pergi dari RW-> R-> I, atau mengubah alamat.
Saya pikir itu adil untuk mengatakan bahwa setiap kali jenis baru caching non-koheren seperti TLB telah ditambahkan, beberapa OS telah rusak, karena itu memiliki asumsi tersirat bahwa ini tidak dilakukan.
Perusahaan baru . lengkungan. Usulan se baru dimulai "3 bulan lalu". Saya pikir ada yang sebelumnya yang tidak pernah berhasil keluar dari area51 (tidak cukup banyak pengikut?).
Jawaban:
Ya, sejauh yang saya tahu, pada prosesor Intel x86-64, ketika miss TLB terjadi dan prosesor sedang berjalan di halaman tabel, akses memori off-chip melewati hierarki cache.
Saya masih sedikit kabur pada beberapa detail, dan saya harap jawaban lain akan mengisinya - bukankah ada manual Intel atau AMD yang menggambarkan halaman berjalan dalam detail yang luar biasa? Pemahaman saya adalah:
Diagram di halaman 2 dari Thomas W. Barr, Alan L. Cox, Scott Rixner. "Caching Terjemahan: Lewati, Jangan Berjalan (Tabel Halaman)" yang menarik garis antara "Entri yang disimpan oleh cache MMU" dan "entri yang disimpan oleh cache data L2". (Ini mungkin makalah yang berguna bagi orang yang mendesain CPU baru , yang benar-benar sesuai topik untuk "Desain elektronik").
Stephane Eranian dan David Mosberger. "Memori Virtual di Kernel Linux IA-64" dan Ulrich Drepper. "Apa yang harus diketahui oleh setiap programmer tentang memori" (Ini mungkin merupakan makalah yang berguna bagi orang yang menulis sistem operasi yang berhubungan dengan tabel halaman IA-64, yang sedikit tidak sesuai topik untuk ED - mungkin Stack Overflow dengan "operating- tag "sistem atau " osdev " atau wiki OSDev.org akan menjadi tempat yang lebih baik untuk topik itu).
Tabel A-10 pada Halaman 533 dari Intel. "Manual Pengembang Perangkat Lunak Arsitektur Intel® 64 dan IA-32" "PAGE_WALKS.CYCLES ... dapat memberi petunjuk apakah sebagian besar halaman-berjalan dipenuhi oleh cache atau menyebabkan kehilangan cache L2."
sumber
invlpguntuk membatalkan caching TLB apa pun untuk addr tambahan yang diberikan. Jika trotoar HW tidak menemukan entri untuk alamat virtual itu, atau izin entri tidak memungkinkan akses, Anda mendapatkan#PFpengecualian. OS menangani itu dengan memperbarui tabel halaman (mungkin setelah paging dalam data dari disk, atau melakukan copy-on-write), dan kemudian melanjutkan sehingga load / store yang bermasalah akan kembali berjalan dan trotoar HW akan berhasil.Saya cenderung setuju bahwa ini termasuk dalam stackexchange arsitektur komputer, bukan stackexchange elektronik, tetapi karena ini ada di sini:
@davidcary benar.
Beberapa sejarah:
Intel x86 page table walks TIDAK di-cache hingga P5, alias Pentium. Lebih tepatnya, akses memory table table walk tidak di-cache, melewati cache. Karena sebagian besar mesin hingga saat itu adalah write-through, mereka menerima nilai yang konsisten dengan cache. Tapi mereka tidak mengintip cache.
P6, alias Pentium Pro, dan AFAIK semua pemroses tabel berjalan selanjutnya diizinkan untuk mengakses cache, dan menggunakan nilai yang ditarik dari cache. Jadi, mereka bekerja dengan cache write-back. (Tentu saja Anda dapat menempatkan tabel halaman dalam memori yang tidak dapat dipadamkan, didefinisikan, misalnya oleh MTRR. Tapi itu adalah kerugian kinerja yang besar, meskipun dapat berguna untuk debugging OS.)
By the way, ini "mengakses tabel berjalan memori dapat mengakses cache data" terpisah dari "entri tabel halaman dapat disimpan (di-cache) dalam TLB Ttranslation Lookaside Buffer)." Pada beberapa mesin, TLB disebut "Terjemahan Cache".
Masalah terkait lainnya adalah bahwa interior node dari tabel halaman mungkin di-cache dalam lebih banyak lagi struktur data mirip TLB, misalnya cache PDE.
Satu perbedaan utama: cache data adalah koheren, dan diintip. Tetapi cache TLB dan PDE tidak diintip, yaitu tidak koheren. Intinya adalah bahwa, karena tabel halaman mungkin di-cache dalam TLB dan koheran PDE yang tidak koheren, dll, perangkat lunak harus secara eksplisit menyiram entri individual atau grup massal (seperti, seluruh TLB), ketika entri tabel halaman yang mungkin sudah begitu cache diubah. Setidaknya ketika diubah dengan cara "berbahaya", pergi dari RW-> R-> I, atau mengubah alamat.
Saya pikir itu adil untuk mengatakan bahwa setiap kali jenis baru caching non-koheren seperti TLB telah ditambahkan, beberapa OS telah rusak, karena itu memiliki asumsi tersirat bahwa ini tidak dilakukan.
sumber