Temu Duga Sistem Pengendalian: Bagaimana Memori Maya dan Page Fault Berfungsi?

Soalan dan Senario yang Berkenaan

Satu perkhidmatan Linux menggunakan mmap untuk memetakan indeks baca sahaja 20 GiB semasa permulaan, kemudian fork 8 proses pekerja. Pemantauan menunjukkan:

• memori maya setiap proses meningkat kira-kira 20 GiB sejurus selepas pemetaan dicipta;
• RSS tidak meningkat dengan jumlah yang sama serta-merta, tetapi meningkat apabila pertanyaan menyentuh lebih banyak bahagian indeks;
• permintaan pertama selepas permulaan sejuk (cold start) mempunyai kependaman yang lebih tinggi dan lebih banyak major page fault;
• mengulangi pertanyaan yang sama adalah lebih pantas dan menghasilkan major fault yang jauh lebih sedikit.

Terangkan bagaimana alamat maya menjadi alamat fizikal, bagaimana TLB miss berbeza daripada page fault, apa maksud minor dan major page fault pada Linux, dan mengapa menjumlahkan RSS kesemua 8 pekerja boleh melebih-lebihkan penggunaan memori fizikal. Akhiri dengan kaedah untuk mengesahkan kesesakan (bottleneck) dan mengurangkan kependaman permulaan sejuk.

Soalan ini sesuai untuk temu duga bahagian belakang (backend), infrastruktur, perisian sistem, SRE, dan kejuruteraan prestasi. Pemetaan 20 GiB, 8 pekerja, dan saiz halaman 4 KiB yang digunakan di bawah adalah andaian latihan hipotesis, bukan ukuran pengeluaran daripada sumber. Indeks tersebut ialah pemetaan fail baca sahaja. Memori tanpa nama (anonymous memory), pemetaan peribadi boleh tulis, had memori kontena, dan sistem masa nyata (real-time) akan mengubah siasatan ini.

Apa yang Dinilai oleh Penemu Duga

Isyarat pertama adalah sama ada calon memisahkan empat lapisan. Ruang alamat maya menerangkan perkara yang boleh dialamatkan oleh sesuatu proses. Jadual halaman (page tables) menyimpan terjemahan dan kebenaran. TLB menyimpan cache terjemahan terkini. Halaman fizikal mengandungi data yang sedang berada di dalam RAM. Jawapan asas menyatakan bahawa memori maya boleh melebihi memori fizikal; jawapan yang kukuh menghuraikan langkah demi langkah arahan load, termasuk TLB hit, semakan jadual halaman (page-table walk), fault yang boleh dibaiki, dan akses yang tidak sah.

Isyarat kedua adalah mengenali bahawa TLB miss bukanlah page fault. Jika terjemahan tiada dalam TLB tetapi entri jadual halaman sah dan menetap (resident), pemproses boleh melengkapkan semakan jadual halaman dan mengisi TLB. Page fault berlaku apabila keadaan jadual halaman semasa tidak dapat memenuhi akses tersebut, seperti halaman yang tidak menetap (nonresident page), penulisan pertama yang memerlukan copy-on-write, atau pelanggaran kebenaran.

Isyarat ketiga adalah tafsiran yang betul terhadap pembilang (counters) Linux. Minor fault tidak memerlukan I/O cakera. Halaman tersebut mungkin sudah berada dalam cache halaman (page cache) tetapi belum dipetakan ke dalam proses ini, atau kernel mungkin sedang memperuntukkan halaman tanpa nama atau melengkapkan copy-on-write. Major fault memerlukan I/O cakera. Ia boleh memuatkan memori tanpa nama yang telah diswap, tetapi ia juga boleh membaca pemetaan bersandarkan fail (file-backed mapping) yang tiada dalam cache halaman. Oleh itu, "major fault bermaksud swap" adalah tidak betul.

Akhir sekali, penemu duga mahukan gelung bukti (evidence loop). Jawapan yang kukuh menyelaraskan kependaman permintaan, perbezaan nilai fault (fault deltas), pemastautinan halaman fail, I/O peranti blok, RSS/PSS, dan tekanan memori dalam tetingkap masa yang sama sebelum memilih pemanasan (warm-up), reka letak indeks yang berbeza, petunjuk akses kernel, atau set kerja (working set) yang lebih kecil.

Soalan Penjelasan Sebelum Menjawab

• Adakah ini memori bersandarkan fail atau tanpa nama, dan adakah pemetaan itu MAP_SHARED atau MAP_PRIVATE? Halaman fail baca sahaja boleh dikongsi melalui cache halaman. Halaman boleh tulis peribadi mungkin menjadi khusus untuk proses selepas copy-on-write.
• Berapa besarkah set kerja panas (hot working set), dan adakah akses secara berjujukan atau rawak? Jika 95% permintaan hanya menyentuh kawasan panas 2 GiB, memanaskan kesemua 20 GiB menambah tekanan permulaan dan memori. Imbasan berjujukan dan carian rawak juga memerlukan pilihan read-ahead yang berbeza.
• Adakah mmap berlaku sebelum atau selepas fork? Kedua-dua pendekatan boleh memetakan fail yang sama, tetapi pemetaan sebelum fork memudahkan pekerja mewarisi satu konfigurasi. Setiap proses masih mempunyai jadual halaman dan keadaan TLB sendiri.
• Adakah major fault meningkat pada masa yang sama dengan bacaan blok dan kependaman ekor (tail latency)? Korelasi itu diperlukan sebelum menyalahkan demand paging bagi kebanyakan kos permulaan sejuk. Ketepuan CPU, kunci (locks), storan jauh, dan pemulaan indeks mungkin wujud bersama.
• Adakah swap didayakan, adakah terdapat had memori kontena atau cgroup, dan adakah penebusan semula (reclaim) berlaku baru-baru ini? Pemetaan bersandarkan fail boleh menjana major fault tanpa swap. Tekanan memori boleh menyingkirkan halaman fail yang dimuatkan baru-baru ini dan menyebabkan fault berulang.
• Apakah SLO kesediaan (readiness SLO)? Perkhidmatan yang mesti menerima trafik dalam masa 10 saat tidak boleh mengimbas 20 GiB secara membuta tuli. Belanjawan pemulaan yang lebih panjang mungkin membenarkan fault terpilih dipindahkan sebelum kesediaan.

Rangka Kerja Jawapan 30 Saat

“mmap mencipta julat maya bersandarkan fail tanpa membaca kesemua 20 GiB, jadi VIRT melonjak manakala RSS meningkat pada sentuhan pertama. CPU menyemak TLB; miss boleh diselesaikan melalui semakan jadual halaman apabila entri adalah sah dan menetap, manakala page fault memerlukan pembaikan kernel. Minor fault Linux tidak memerlukan I/O cakera; major fault memerlukannya, jadi halaman fail sejuk meningkatkan major fault dan kependaman permintaan sehingga cache halaman dipanaskan. Halaman baca sahaja boleh dikongsi oleh 8 pekerja, jadi penjumlahan RSS mengira mereka dua kali; gunakan PSS. Hubung kaitkan perbezaan fault, RssFile/PSS, I/O bacaan, dan p99, kemudian panaskan halaman panas sahaja atau uji madvise dan MAP_POPULATE dalam belanjawan permulaan.”

Rangka kerja ini menerangkan pemerhatian, memisahkan dua kekeliruan lazim, dan ditutup dengan pengukuran serta keputusan. Jawapan yang lengkap juga harus menerangkan laluan fault dan keadaan di mana setiap pengoptimuman gagal.

Huraian Terperinci Langkah Demi Langkah

Langkah 1: Pisahkan Ruang Alamat, Pemetaan, dan Halaman Menetap

Memori maya memberikan setiap proses ruang alamat yang bebas. Alamat maya boleh dilihat sebagai nombor halaman maya ditambah dengan ofset (offset). Jadual halaman memetakan nombor halaman maya kepada bingkai halaman fizikal (physical page frames) dan menyimpan keadaan atau kebenaran seperti hadir (present), boleh tulis (writable), dan boleh laksana (executable). Jadual halaman pelbagai peringkat memperuntukkan peringkat lebih rendah hanya untuk julat alamat yang digunakan, mengelakkan jadual linear yang besar untuk ruang alamat yang jarang (sparse).

Hasil serta-merta pemetaan fail 20 GiB ialah kawasan memori maya 20 GiB. Pemetaan menerangkan bagaimana julat alamat itu sepadan dengan fail; ia tidak memerlukan kernel membaca keseluruhan fail serta-merta. Akibatnya:

• VIRT atau VmSize boleh meningkat kira-kira 20 GiB sekali gus;
• halaman fail yang tidak disentuh tidak perlu berada dalam RAM;
• apabila pertanyaan membaca halaman buat kali pertama, kernel boleh memuatkannya ke dalam cache halaman dan memasang pemetaan jadual halaman;
• RSS mengira bahagian yang menetap, jadi ia berkembang apabila set kerja disentuh.

Dengan mengandaikan halaman 4 KiB, menyentuh keseluruhan pemetaan 20 GiB bermakna menyentuh:

20 × 2^30 ÷ 4096 = 5,242,880 halaman.

Pengiraan itu menunjukkan mengapa "panaskan segala-galanya" bukanlah percuma. Jika hanya kawasan kecil yang panas, mengimbas lebih daripada 5.24 juta halaman membawa data bernilai rendah ke dalam memori dan mungkin menyingkirkan entri cache berguna yang lain.

Langkah 2: Menelusuri TLB dan Jadual Halaman

Apabila CPU melaksanakan load, store, atau pengambilan arahan (instruction fetch), ia mesti menterjemah alamat maya:

1. cari nombor halaman maya dalam TLB;
2. jika berlaku TLB hit, dapatkan bingkai fizikal dan gabungkannya dengan ofset;
3. jika berlaku TLB miss, biarkan perkakasan atau sistem pengendalian merujuk jadual halaman;
4. jika entri adalah sah, dibenarkan, dan menetap, simpan terjemahan dalam cache TLB dan cuba semula atau teruskan;
5. jika entri semasa tidak dapat memenuhi akses tersebut, masuk ke laluan page-fault.

TLB miss bermaksud "cache terjemahan terlepas (missed)." Page fault bermaksud "keadaan jadual halaman semasa tidak dapat melengkapkan akses ini." Yang pertama mungkin hanya menambah semakan jadual halaman. Yang kedua memasuki kernel untuk memutuskan sama ada akses itu sah dan boleh dibaiki. Mengelirukan kedua-duanya membawa kepada dakwaan yang salah tentang perkara yang boleh diperbaiki oleh huge pages, prefetching, atau storan yang lebih pantas.

Langkah 3: Bahagikan Page Fault kepada Kes Boleh Dibaiki dan Maut

Page fault ialah pengecualian (exception), bukan secara automatik merupakan pepijat program. Kernel terlebih dahulu memeriksa alamat dan kebenaran:

• Halaman fail yang sah tetapi tidak menetap: baca halaman fail atau petakan halaman cache halaman yang sedia ada.
• Akses sah pertama ke memori tanpa nama: bacaan pertama boleh memetakan zero page yang dikongsi, manakala penulisan pertama memperuntukkan halaman fizikal sebenar.
• Penulisan pertama selepas fork ke halaman peribadi: lakukan copy-on-write dan berikan penulis salinan peribadi.
• Alamat tidak dipetakan atau kebenaran dilarang: jika akses tidak dapat dibaiki, hantar isyarat seperti SIGSEGV.

Selepas membaiki fault, kernel mengemas kini jadual halaman dan mencuba semula arahan yang mengalami fault. Jika I/O storan diperlukan, proses akan disekat (block) semasa menunggu dan penjadual boleh menjalankan tugas lain. Laluan menyekat itulah sebabnya major fault boleh meningkatkan kependaman bagi setiap permintaan secara langsung.

Langkah 4: Tafsirkan Minor dan Major Fault dengan Betul

Linux menggunakan perbezaan operasi: adakah pengendalian fault memerlukan I/O cakera?

• Kesalahan halaman kecil (minor fault): tiada I/O cakera diperlukan. Halaman fail mungkin sudah berada dalam cache halaman tetapi belum dipetakan ke dalam proses ini. Memori tanpa nama mungkin diwujudkan atas permintaan, atau copy-on-write boleh diselesaikan dalam memori.
• Kesalahan halaman besar (major fault): I/O cakera diperlukan. Dalam senario ini, pertanyaan sejuk pertama mungkin menyentuh halaman indeks yang tiada dalam cache halaman, memaksa kernel membacanya daripada fail indeks.

Dua contoh sangkalan mengukuhkan jawapan:

1. Major fault tidak memerlukan swap. Pemetaan bersandarkan fail yang sejuk boleh memerlukan I/O storan.
2. Minor fault bukan percuma. Ia masih boleh memasuki kernel, memperuntukkan halaman, mengemas kini jadual halaman, dan mencuba semula arahan; ia cuma mengelakkan laluan I/O cakera yang lebih perlahan.

Langkah 5: Terangkan Mengapa Penjumlahan RSS Mengelirukan

Apabila 8 pekerja membaca pemetaan fail baca sahaja yang sama, halaman fail asas boleh dikongsi melalui cache halaman. RSS setiap proses merangkumi halaman menetap yang dipetakan ke dalam proses tersebut, jadi halaman fizikal yang sama boleh muncul dalam pelbagai nilai RSS. Menjumlahkan kesemua 8 nilai RSS mengira halaman yang dikongsi secara berulang kali.

Sekurang-kurangnya, bezakan:

• VmSize: saiz ruang alamat maya;
• VmRSS: semua halaman yang menetap untuk proses ini;
• RssFile: pemetaan bersandarkan fail yang menetap;
• RssAnon: memori tanpa nama yang menetap;
• PSS: halaman dikongsi dibahagikan secara berkadar antara proses yang memetakannya;
• VmPTE: memori yang digunakan oleh entri jadual halaman;
• VmSwap: data peribadi tanpa nama yang diswap untuk proses itu, bukan pandangan lengkap pemetaan fail.

/proc/<pid>/smaps_rollup menyediakan agregat RSS dan PSS untuk semua pemetaan dalam sesuatu proses. Apabila menganggarkan jejak fizikal yang boleh dikaitkan dengan 8 pekerja tersebut, jumlah PSS secara amnya lebih berguna daripada jumlah RSS, walaupun persaingan cache halaman sistem dan proses yang tidak berkaitan masih memainkan peranan.

Langkah 6: Sahkan Kesesakan dengan Pemerhatian yang Boleh Diulang

Bina satu garis masa dan bukannya membuat kesimpulan daripada satu tangkapan skrin top. Dalam persekitaran ujian Linux, kumpulkan:

grep -E 'VmSize|VmRSS|RssAnon|RssFile|VmPTE|VmSwap' /proc/$pid/status
cat /proc/$pid/smaps_rollup
perf stat -e page-faults,minor-faults,major-faults -p "$pid" -- sleep 30

Kemudian jalankan set pertanyaan yang sama tepat sebanyak dua kali:

1. selepas permulaan sejuk, rekodkan p50, p95, dan p99 permintaan, perbezaan fault, bacaan blok, dan RSS/PSS;
2. ulangi serta-merta dengan data, keserentakan (concurrency), dan laluan kod yang sama;
3. jika major fault, I/O bacaan, dan kependaman ekor semuanya tinggi pada larian pertama dan jauh lebih rendah pada larian kedua, halaman fail yang dimuatkan atas permintaan adalah penjelasan utama yang kukuh;
4. jika major fault jarang berlaku manakala kependaman kekal tinggi, periksa CPU, kunci, panggilan jauh, dan pemulaan indeks dalaman;
5. ulangi di bawah tekanan memori terkawal untuk melihat sama ada penebusan semula halaman panas mewujudkan semula lonjakan kependaman.

Pembilang fault adalah kumulatif, jadi bandingkan perbezaan (deltas) dalam tetingkap masa yang sama dan bukannya jumlah sepanjang hayat proses. Ukur pekerja secara berasingan supaya fault pengimbas latar belakang tidak tersilap dikaitkan dengan permintaan dalam talian.

Langkah 7: Pilih Pengoptimuman daripada Set Kerja dan SLO

Pilihan yang paling agresif tidak semestinya yang terbaik secara automatik:

1. Kekalkan demand paging: permulaan terpantas dan memori berkadar dengan set kerja sebenar. Ia sesuai dengan beban kerja yang bertolak ansur dengan trafik sejuk atau mempunyai kawasan panas yang berubah-ubah, dengan kos kependaman sentuhan pertama.
2. Panaskan halaman panas sahaja: jalankan pertanyaan representatif atau sentuh halaman daripada manifes set panas sebelum kesediaan. Ia memindahkan kos terhad lebih awal dan biasanya lebih terkawal daripada mengimbas 20 GiB, tetapi definisi set panas mesti dikekalkan.
3. Sediakan petunjuk akses madvise: MADV_WILLNEED menyatakan julat itu akan diperlukan tidak lama lagi, membenarkan read-ahead. Corak berjujukan dan rawak juga mempunyai petunjuk yang berbeza. Ini adalah petunjuk prestasi, bukan jaminan pemastautinan.
4. Uji MAP_POPULATE: ia mempralengkapkan jadual halaman (prefaults) dan menyebabkan read-ahead untuk pemetaan fail, mengurangkan fault yang menyekat kemudian hari. Pertukaran (tradeoff) adalah mmap dan permulaan yang lebih perlahan, I/O tertumpu dan tekanan memori, serta hakikat bahawa populasi yang tidak lengkap tidak semestinya menggagalkan panggilan.
5. Tambah baik reka letak indeks dan saiz set kerja: asingkan metadata panas daripada data sejuk, perbaiki lokaliti, dan kurangkan akses rentas halaman rawak. Ini lebih tahan lama daripada prefetching secara membuta tuli.
6. Kawal pintu trafik (gate traffic): dedahkan kesediaan penuh selepas liputan set panas yang ditentukan atau sasaran kadar fault dicapai, dengan tamat masa supaya nod tidak kekal dalam keadaan belum sedia selama-lamanya.

Huge pages boleh mengurangkan tekanan TLB, tetapi ia tidak menghapuskan I/O fail atau membetulkan set kerja yang dipilih dengan buruk. Nilainya hanya selepas bukti mengenal pasti TLB miss sebagai kesesakan utama dan granulariti memori, pemecahan (fragmentation), serta persekitaran penggunaan boleh diterima.

Contoh Jawapan Berkualiti Tinggi

“Saya mula-mula akan mengesahkan bahawa kawasan 20 GiB ialah pemetaan fail baca sahaja dan bahawa mmap berlaku sebelum fork. mmap mewujudkan hubungan antara julat alamat maya dan fail; ia tidak membaca keseluruhan fail ke dalam memori fizikal. Oleh itu, VmSize setiap pekerja meningkat kira-kira 20 GiB serta-merta, manakala RSS berkembang hanya apabila pertanyaan menyentuh halaman.

Sesuatu akses menyemak TLB terlebih dahulu. TLB miss hanya menyatakan bahawa cache terjemahan terkini kekurangan entri. Jika entri jadual halaman sah, dibenarkan, dan menetap, semakan jadual halaman dan pengisian TLB sudah mencukupi; tiada page fault. Fault hanya berlaku apabila keadaan jadual halaman tidak dapat memenuhi akses tersebut, seperti halaman fail yang tidak menetap, penulisan copy-on-write pertama selepas fork, atau kebenaran yang tidak sah.

Bagi pembilang Linux, saya mentakrifkan minor sebagai tiada I/O cakera diperlukan dan major sebagai I/O cakera diperlukan. Selepas permulaan sejuk, halaman indeks yang digunakan oleh permintaan pertama mungkin tiada dalam cache halaman, jadi membacanya menyebabkan major fault dan kependaman ekor yang lebih tinggi. Mengulangi pertanyaan yang sama mengenai cache halaman, jadi ia mungkin hanya menyebabkan minor fault atau menggunakan pemetaan sedia ada dan kependaman menurun. Major fault tidak terhad kepada swap; pemetaan bersandarkan fail boleh menjananya walaupun pada mesin tanpa swap.

Pekerja boleh berkongsi halaman fail baca sahaja, tetapi RSS setiap pekerja mengira halaman dikongsi yang dipetakannya. Saya tidak akan menjumlahkan nilai RSS secara langsung. Saya akan memeriksa PSS, RssFile, RssAnon, dan VmPTE dalam /proc/<pid>/smaps_rollup, kemudian menyelaraskannya dengan bacaan blok, perbezaan minor dan major fault, serta p99 permintaan dalam tetingkap 30 saat yang sama.

Untuk pengesahan, saya akan menjalankan set pertanyaan yang sama sebanyak dua kali. Jika major fault, I/O bacaan, dan p99 tinggi pada larian pertama dan menurun bersama-sama pada larian kedua, ini menyokong pemuatan atas permintaan (demand loading) sebagai punca utama. Saya kemudiannya akan mengukur set kerja panas yang sebenar. Jika hanya 2 GiB daripada indeks 20 GiB yang panas, saya akan memanaskan kawasan tersebut sebelum kesediaan dan menggunakan petunjuk madvise yang sesuai untuk akses berjujukan atau rawak. Jika SLO membenarkan lebih banyak kos permulaan, saya akan menjalankan ujian A/B dengan MAP_POPULATE. Saya tidak akan mengimbas keseluruhan fail secara lalai atau menganggap huge pages sebagai pembaikan umum untuk page fault. Keputusan akhir akan membandingkan masa permulaan, p99 minit pertama, kadar major-fault, PSS, dan kestabilan selepas penebusan semula memori.”

Jawapan ini menghubungkan konsep, pemerhatian, dan keputusan menjadi satu rantaian yang boleh diuji. Jika penemu duga menukar jenis pemetaan, set kerja, atau SLO kesediaan, rangka kerja yang sama masih menghasilkan pilihan berbeza yang boleh dipertahankan.

Kesilapan Lazim

• Menganggap VIRT sebagai RAM yang telah digunakan → pemetaan fail boleh menempah julat alamat tanpa menjadikan setiap halaman menetap → periksa VmSize, RSS, PSS, dan jenis pemetaan bersama-sama.
• Menyamakan TLB miss dengan page fault → entri jadual halaman yang sah dan menetap hanya memerlukan terjemahan → terangkan carian TLB, semakan jadual halaman, dan keadaan fault secara berasingan.
• Mendakwa setiap page fault membaca cakera → cache halaman yang kena (hits), zero pages tanpa nama, dan copy-on-write boleh menghasilkan minor fault → gunakan perbezaan I/O minor/major Linux.
• Mendakwa major fault hanya datang daripada swap → halaman bersandarkan fail yang tidak dicache juga memerlukan I/O storan → kenal pasti sama ada halaman yang mengalami fault adalah tanpa nama atau bersandarkan fail.
• Menjumlahkan RSS kesemua 8 pekerja → halaman fail dikongsi dikira berulang kali → gunakan PSS untuk mengagihkan halaman dikongsi dan bandingkan RssFile dengan RssAnon.
• Membaca jumlah fault sepanjang hayat proses → ia tidak membuktikan hubungan dengan tetingkap permintaan perlahan tertentu → bandingkan perbezaan fault, I/O, dan kependaman dalam selang masa yang sama.
• Mengimbas kesemua 20 GiB semasa permulaan → ini boleh membazirkan I/O, melambatkan kesediaan, dan menyingkirkan halaman yang lebih berguna → ukur set panas dan panaskan hanya apa yang diperlukan oleh SLO.
• Menganggap MADV_WILLNEED atau MAP_POPULATE menghapuskan fault masa hadapan → yang pertama ialah petunjuk, yang kedua mungkin tidak lengkap, dan halaman boleh ditebus semula kemudian → uji tingkah laku permulaan sejuk dan tekanan memori.
• Mendayakan huge pages serta-merta → ia terutamanya mengubah liputan terjemahan dan granulariti peruntukan, bukan I/O fail atau kualiti set kerja → buktikan terlebih dahulu bahawa TLB miss adalah dominan.

Soalan Susulan dan Jawapan

Susulan 1: Tiada swap pada mesin tersebut. Mengapakah masih terdapat major page fault?

Major bermaksud bahawa pengendalian fault memerlukan I/O cakera; sumbernya tidak semestinya swap. Indeks dalam senario ini adalah bersandarkan fail. Pada akses pertama ke halaman fail yang tiada dalam cache halaman, kernel mesti membacanya daripada sistem fail, jadi akses tersebut boleh menjana major fault. Periksa RssFile, laluan yang dipetakan, dan bacaan blok dan bukannya hanya menyemak VmSwap.

Susulan 2: Seorang pekerja lain telah membaca halaman fail yang sama. Apakah yang berlaku pada akses pertama pekerja ini?

Halaman tersebut mungkin sudah berada dalam cache halaman sistem manakala pekerja ini kekurangan pemetaan jadual halaman untuknya. Mewujudkan pemetaan itu biasanya tidak memerlukan I/O cakera dan boleh muncul sebagai minor fault. Akses terkemudian mungkin masih mengalami TLB miss, tetapi jika entri jadual halaman sah, itu bukanlah page fault.

Susulan 3: Mengapakah menulis sejumlah kecil selepas fork boleh meningkatkan PSS?

Halaman peribadi pada mulanya boleh dikongsi melalui copy-on-write. Pada penulisan pertama, kernel mencipta salinan peribadi untuk pekerja yang menulis dan mengemas kini jadual halamannya. Halaman yang dikongsi kini menjadi milik satu proses sepenuhnya, jadi PSS meningkat. Fault tersebut biasanya tidak memerlukan I/O cakera, tetapi peruntukan dan penyalinan masih memakan masa. Indeks baca sahaja harus mengelakkan penulisan tidak sengaja ke pemetaan peribadi.

Susulan 4: Apakah yang berlaku jika akses adalah rawak tetapi perkhidmatan menggunakan MADV_SEQUENTIAL?

Petunjuk yang tidak sepadan boleh mencetuskan read-ahead yang tidak berguna, memuatkan halaman yang tidak akan digunakan dan meningkatkan I/O. Untuk carian titik rawak, uji MADV_RANDOM atau dasar lalai; jika set panas diketahui, pra-pengambilan yang disasarkan adalah lebih baik. Nilai setiap petunjuk berdasarkan fault, I/O, PSS, dan kependaman dan bukannya berdasarkan namanya.

Susulan 5: Bilakah MAP_POPULATE sesuai digunakan?

Ia berbaloi untuk dieksperimen apabila permulaan boleh meluangkan lebih banyak masa dan I/O, kependaman sentuhan pertama dalam talian mesti stabil, dan julat pemetaan yang bakal digunakan boleh diramal secara munasabah. Ia boleh membazir apabila pemetaan jauh lebih besar daripada set panas, nod diskalakan dengan kerap, atau tekanan memori akan menebus semula halaman tidak lama lagi. Kegagalan populasi juga tidak semestinya menggagalkan mmap, jadi pemastautinan sebenar dan fault terkemudian mesti diukur.

Susulan 6: Bagaimanakah anda membezakan pergolakan page-fault (page-fault churn) daripada kebocoran memori (memory leak) yang sebenar?

Kebocoran biasanya menunjukkan memori tanpa nama peribadi atau objek yang tidak boleh ditebus semula berkembang secara berterusan walaupun di bawah trafik yang stabil. Pertumbuhan dalam set kerja bersandarkan fail muncul lebih banyak dalam RssFile dan cache halaman serta mungkin berkurangan selepas penebusan semula. Bandingkan RssAnon, RssFile, PSS, VmSwap, dan profil timbunan (heap) atau objek, kemudian ulangi di bawah trafik yang stabil dan tekanan memori terkawal. Pertumbuhan RSS sahaja tidak dapat membezakan kedua-duanya.