CPU manakah yang mendukung halaman 1GB?

Beberapa CPU Intel mendukung halaman 1GB. Ini diidentifikasi dengan melihat CPUID 0x80000001, EDX bit 26 . Kernel Linux mengekspos ini via /proc/cpuinfosebagai pdpe1gbflag .

Di mana kita mengetahui CPU mana yang mendukung ini, dan mana yang tidak? Atau lini produk apa yang mendukung fitur ini? Tidak ada apa pun di halaman ARK Intel yang menunjukkan dukungan untuk fitur ini.

CPU yang melakukan dukungan halaman 1GB:

Xeon E5620 (Westmere)
Core i5-4250U ( Haswell, Mobile )

CPU lain yang tidak mendukung halaman 1GB:

Xeon E5506 (Nehalem)
Core i7-2720QM (Sandy Bridge, Mobile)
Core i5-2500K (Sandy Bridge)

cpu

— Jonathon Reinhart
sumber

Terkait: Bagaimana cara menggunakan halaman Intel Westmere 1GB di Linux?

— Jonathon Reinhart

Menurut halaman ini :

sebagai tambahan untuk halaman 4 KB standar mereka prosesor x86-64 yang lebih baru, seperti prosesor AMD64 AMD yang lebih baru dan Intel Westmere dan prosesor yang lebih baru dapat menggunakan halaman 1 GB dalam mode panjang

Tampaknya benar karena itu adalah fitur baru dari CPU Westmere .

— Viacheslav Rodionov
sumber

Ya, saya pasti melihat semua halaman Wikipedia itu! Namun, jawaban ini tidak benar. Sandy Bridge lebih baru daripada Westmere, dan saya sekarang memiliki dua CPU Sandy Bridge yang tidak mendukungnya.

— Jonathon Reinhart

@ JonathonReinhart: kerugian besar untuk Hugepages untuk penggunaan umum, esp. 1G halaman, adalah bahwa seluruh hugepage mengikat banyak RAM fisik. Jika suatu proses mengalokasikan 1GiB secara normal, hanya bagian-bagian yang pernah disentuh yang benar-benar mengambil memori virtual. (overcommit bahkan memungkinkan alokasi yang tidak memiliki cukup ruang swap untuk ditangani oleh kernel). Linux tidak dapat mem-page hugepages ke disk bahkan ketika suatu proses dihentikan, jadi alokasi hugepage secara efektif menyematkan / mengunci banyak memori fisik.

— Peter Cordes

2M hugepages masuk akal ketika mereka tidak akan ditinggalkan setengah kosong (misalnya ketika Anda tahu pasti bahwa Anda sedang akan menulis setiap 4k dari 2M pula), namun kurang dari paging adalah masalah besar. Merancang perangkat lunak serba guna agar berfungsi buruk pada desktop yang terbatas memori bukanlah ide yang baik. Saya tidak berpikir Anda bahkan dapat mmap file pada disk dengan 2M hugepages, tetapi itu akan menjadi ide yang buruk untuk executable karena akan ada beberapa halaman 4k dalam blok 2M yang tidak tersentuh. Ini dapat diusir dari pagecache (dengan asumsi mereka prefetched), membebaskan RAM.

— Peter Cordes

Dengan CPU saat ini yang memiliki TLB multi-level, total waktu yang dihabiskan untuk melewatkan TLB mungkin tidak terlalu buruk, bukan? Saya belum membuat profil tentang hal-hal besar seperti firefox. Saya akan tertarik untuk melihat ringkasan yang dapat dibaca tentang berapa banyak waktu yang dihabiskan untuk melewatkan TLB, (terutama halaman-berjalan), dan hal-hal seperti L1 I-cache merindukan. Saya tahu saya bisa menunjukkannya perf... Bahkan jika Anda memang ingin menggunakan hugepage 2M untuk firefox, saya kira banyak data internalnya dialokasikan dalam potongan yang lebih kecil dari itu. Akan ada overhead untuk memastikan Anda meminimalkan fragmentasi eksternal alokasi di dalam buffer hugepage.

— Peter Cordes

Kehilangan TLB mahal pada operasi memori-tinggi, akses acak, seperti banyak aplikasi database. Halaman besar membuat perbedaan yang signifikan - tetapi bahkan di sana, mereka berbicara tentang halaman 2MB, bukan 1GB. OS adalah kemungkinan pengguna 1GB halaman melalui pemetaan langsung seluruh ruang alamat fisik.

— GreenReaper