Wawancara Sistem Operasi: Bagaimana Cara Kerja Virtual Memory dan Page Fault?

Pertanyaan dan Skenario yang Berlaku

Sebuah layanan Linux menggunakan mmap untuk memetakan indeks read-only sebesar 20 GiB saat startup, kemudian melakukan fork terhadap 8 proses worker. Pemantauan menunjukkan:

• virtual memory setiap proses bertambah sekitar 20 GiB segera setelah pemetaan dibuat;
• RSS tidak langsung bertambah dalam jumlah yang sama, tetapi meningkat saat kueri menyentuh lebih banyak area indeks;
• permintaan pertama setelah cold start memiliki latensi lebih tinggi dan lebih banyak major page fault;
• mengulangi kueri yang sama menjadi lebih cepat dan menghasilkan jauh lebih sedikit major fault.

Jelaskan bagaimana alamat virtual menjadi alamat fisik, perbedaan antara TLB miss dan page fault, arti minor dan major page fault di Linux, dan mengapa menjumlahkan RSS dari seluruh 8 worker dapat melebih-lebihkan (overstate) konsumsi memori fisik. Akhiri dengan metode untuk memverifikasi bottleneck dan mengurangi latensi cold-start.

Pertanyaan ini cocok untuk wawancara backend, infrastruktur, software sistem, SRE, dan rekayasa performa. Pemetaan 20 GiB, 8 worker, dan ukuran page 4 KiB yang digunakan di bawah ini adalah asumsi latihan hipotetis, bukan pengukuran produksi dari sumber. Indeks tersebut merupakan pemetaan file read-only. Memori anonim, pemetaan privat yang dapat ditulisi, batas memori kontainer, dan sistem real-time akan mengubah proses investigasi.

Apa yang Dinilai oleh Pewawancara

Sinyal pertama adalah apakah kandidat memisahkan empat lapisan. Address space virtual mendeskripsikan apa yang dapat dialamatkan oleh suatu proses. Page table menyimpan translasi dan izin. TLB meng-cache translasi terkini. Page fisik berisi data yang saat ini berada di RAM. Jawaban dasar menyatakan bahwa virtual memory dapat melebihi memori fisik; jawaban yang kuat menelusuri instruksi load, termasuk TLB hit, page-table walk, fault yang dapat diperbaiki, dan akses ilegal.

Sinyal kedua adalah mengenali bahwa TLB miss bukanlah page fault. Jika translasi tidak ada di TLB tetapi entri page-table valid dan residen, prosesor dapat menyelesaikan page-table walk dan mengisi TLB. Page fault terjadi ketika status page-table saat ini tidak dapat memenuhi akses, seperti page non-residen, penulisan pertama yang memerlukan copy-on-write, atau pelanggaran izin.

Sinyal ketiga adalah interpretasi yang benar terhadap counter Linux. Minor fault tidak memerlukan I/O disk. Page tersebut mungkin sudah ada di page cache tetapi belum dipetakan ke dalam proses ini, atau kernel mungkin sedang mengalokasikan page anonim atau menyelesaikan copy-on-write. Major fault memerlukan I/O disk. Ini dapat memuat memori anonim yang di-swap, tetapi juga dapat membaca pemetaan berbasis file (file-backed) yang tidak ada di page cache. Oleh karena itu, anggapan bahwa “major fault berarti swap” adalah tidak tepat.

Terakhir, pewawancara menginginkan alur pembuktian berbasis bukti (evidence loop). Jawaban yang kuat menyelaraskan latensi permintaan, delta fault, residensi file-page, I/O block device, RSS/PSS, dan tekanan memori dalam jendela waktu yang sama sebelum memilih warm-up, tata letak indeks yang berbeda, petunjuk akses kernel, atau working set yang lebih kecil.

Pertanyaan Klarifikasi Sebelum Menjawab

• Apakah ini memori berbasis file atau anonim, dan apakah pemetaannya MAP_SHARED atau MAP_PRIVATE? Page file read-only dapat dibagikan melalui page cache. Page privat yang dapat ditulisi dapat menjadi spesifik untuk proses setelah copy-on-write.
• Seberapa besar hot working set, dan apakah aksesnya sekuensial atau acak? Jika 95% permintaan hanya menyentuh area panas sebesar 2 GiB, melakukan warming pada seluruh 20 GiB akan menambah beban startup dan tekanan memori. Pemindaian sekuensial dan pencarian acak juga memerlukan pilihan read-ahead yang berbeda.
• Apakah mmap terjadi sebelum atau sesudah fork? Kedua pendekatan dapat memetakan file yang sama, tetapi memetakan sebelum fork memudahkan worker untuk mewarisi satu konfigurasi. Setiap proses tetap memiliki page table dan status TLB-nya sendiri.
• Apakah major fault meningkat pada saat yang sama dengan pembacaan blok dan tail latency? Korelasi tersebut diperlukan sebelum menyimpulkan demand paging sebagai penyebab utama sebagian besar biaya cold-start. Saturasi CPU, lock, penyimpanan jarak jauh, dan inisialisasi indeks dapat terjadi secara bersamaan.
• Apakah swap diaktifkan, apakah ada batasan memori kontainer atau cgroup, dan apakah reclaim baru saja terjadi? Pemetaan berbasis file dapat menghasilkan major fault tanpa swap. Tekanan memori dapat mengusir (evict) page file yang baru dimuat dan menyebabkan fault berulang.
• Berapa SLO kesiapan (readiness)? Layanan yang harus menerima lalu lintas dalam 10 detik tidak dapat memindai 20 GiB secara membabi buta. Anggaran inisialisasi yang lebih panjang memungkinkan fault tertentu dipindahkan sebelum status siap.

Kerangka Jawaban 30 Detik

“mmap membuat rentang virtual berbasis file tanpa membaca seluruh 20 GiB, sehingga VIRT melonjak sementara RSS tumbuh saat sentuhan pertama. CPU memeriksa TLB; miss dapat diselesaikan dengan page-table walk ketika entri valid dan residen, sedangkan page fault memerlukan perbaikan kernel. Minor fault di Linux tidak memerlukan I/O disk; major fault memerlukannya, sehingga page file yang dingin meningkatkan major fault dan latensi permintaan hingga page cache menjadi hangat. Page read-only dapat dibagi oleh 8 worker, sehingga penjumlahan RSS menghitungnya ganda; gunakan PSS. Korelasikan delta fault, RssFile/PSS, read I/O, dan p99, lalu lakukan warm-up hanya pada page panas atau uji madvise dan MAP_POPULATE dalam batas anggaran startup.”

Kerangka kerja ini menjelaskan hasil observasi, memisahkan dua kesalahpahaman umum, dan diakhiri dengan pengukuran serta keputusan. Jawaban lengkap juga harus menjelaskan jalur fault dan kondisi di mana setiap optimasi gagal.

Pembahasan Mendalam Langkah Demi Langkah

Langkah 1: Pisahkan Address Space, Pemetaan, dan Page Residen

Virtual memory memberi setiap proses address space yang independen. Alamat virtual dapat dilihat sebagai nomor virtual page ditambah offset. Page table memetakan nomor virtual page ke frame page fisik dan menyimpan status atau izin seperti present, writable, dan executable. Multi-level page table mengalokasikan tingkat yang lebih rendah hanya untuk rentang alamat yang digunakan, menghindari tabel linier yang sangat besar untuk address space yang renggang (sparse).

Hasil langsung dari pemetaan file 20 GiB adalah area virtual memory sebesar 20 GiB. Pemetaan tersebut menjelaskan bagaimana rentang alamat tersebut sesuai dengan file; ini tidak mengharuskan kernel membaca seluruh file secara langsung. Akibatnya:

• VIRT atau VmSize dapat meningkat sekitar 20 GiB sekaligus;
• page file yang belum disentuh tidak perlu berada di RAM;
• ketika kueri pertama kali membaca sebuah page, kernel dapat memuatnya ke dalam page cache dan memasang pemetaan page-table;
• RSS menghitung bagian yang residen, sehingga bertambah seiring disentuhnya working set.

Dengan asumsi ukuran page 4 KiB, menyentuh seluruh pemetaan 20 GiB berarti menyentuh:

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

Perhitungan tersebut menunjukkan mengapa “menghangatkan semuanya” tidak gratis. Jika hanya area kecil yang panas, memindai lebih dari 5,24 juta page akan membawa data bernilai rendah ke dalam memori dan dapat mengusir entri cache lain yang berguna.

Langkah 2: Telusuri TLB dan Page Table

Ketika CPU mengeksekusi instruksi load, store, atau pengambilan instruksi, ia harus menerjemahkan alamat virtual:

1. cari nomor virtual page di TLB;
2. pada TLB hit, dapatkan frame fisik dan gabungkan dengan offset;
3. pada TLB miss, biarkan perangkat keras atau sistem operasi memeriksa page table;
4. jika entri valid, diizinkan, dan residen, cache translasi di TLB lalu ulangi atau lanjutkan;
5. jika entri saat ini tidak dapat memenuhi akses, masuk ke jalur page-fault.

TLB miss berarti “cache translasi tidak ditemukan.” Page fault berarti “status page-table saat ini tidak dapat menyelesaikan akses ini.” Yang pertama mungkin hanya menambah proses page-table walk. Yang kedua masuk ke kernel untuk memutuskan apakah akses tersebut sah dan dapat diperbaiki. Membingungkan keduanya menyebabkan klaim yang salah tentang apa yang dapat diperbaiki oleh huge page, prefetching, atau penyimpanan yang lebih cepat.

Langkah 3: Bagi Page Fault Menjadi Kasus yang Dapat Diperbaiki dan Fatal

Page fault adalah sebuah pengecualian (exception), bukan secara otomatis merupakan bug program. Kernel pertama-tama memeriksa alamat dan izin:

• Page file yang sah tetapi non-residen: baca page file atau petakan page yang sudah ada di page-cache.
• Akses sah pertama ke memori anonim: pembacaan pertama dapat memetakan shared zero page, sedangkan penulisan pertama mengalokasikan page fisik nyata.
• Penulisan pertama setelah fork ke page privat: lakukan copy-on-write dan berikan salinan privat kepada proses yang menulis.
• Alamat yang tidak dipetakan atau izin terlarang: jika akses tidak dapat diperbaiki, kirimkan sinyal seperti SIGSEGV.

Setelah memperbaiki fault, kernel memperbarui page table dan mengulang instruksi yang menyebabkan fault. Jika I/O penyimpanan diperlukan, proses akan memblokir saat menunggu dan scheduler dapat menjalankan tugas lain. Jalur pemblokiran itulah yang menyebabkan major fault dapat secara langsung meningkatkan latensi per permintaan.

Langkah 4: Interpretasikan Minor dan Major Fault dengan Benar

Linux menggunakan perbedaan operasional: apakah penanganan fault memerlukan I/O disk?

• Fault halaman ringan (minor fault): tidak memerlukan I/O disk. Page file mungkin sudah ada di page cache tetapi belum dipetakan ke dalam proses ini. Memori anonim dapat diwujudkan sesuai permintaan, atau copy-on-write dapat diselesaikan di memori.
• Fault halaman berat (major fault): memerlukan I/O disk. Dalam skenario ini, kueri dingin pertama mungkin menyentuh page indeks yang tidak ada di page cache, memaksa kernel membacanya dari file indeks.

Dua contoh sanggahan memperkuat jawaban ini:

1. Major fault tidak selalu memerlukan swap. Pemetaan berbasis file yang dingin dapat memerlukan I/O penyimpanan.
2. Minor fault tidak gratis. Ini mungkin masih masuk ke kernel, mengalokasikan page, memperbarui page table, dan mengulang instruksi; ini hanya menghindari jalur I/O disk yang lebih lambat.

Langkah 5: Jelaskan Mengapa Penjumlahan RSS Menyesatkan

Ketika 8 worker membaca pemetaan file read-only yang sama, page file yang mendasarinya dapat dibagikan melalui page cache. RSS setiap proses mencakup page residen yang dipetakan ke dalam proses tersebut, sehingga page fisik yang sama dapat muncul di beberapa nilai RSS. Menjumlahkan seluruh 8 nilai RSS akan menghitung ganda page yang dibagikan.

Minimal, bedakan antara:

• VmSize: ukuran virtual address-space;
• VmRSS: seluruh page yang residen untuk proses ini;
• RssFile: pemetaan berbasis file yang residen;
• RssAnon: memori anonim yang residen;
• PSS: shared page yang dibagi secara proporsional di antara proses-proses yang memetakannya;
• VmPTE: memori yang dikonsumsi oleh entri page-table;
• VmSwap: data privat anonim yang di-swap untuk proses tersebut, bukan gambaran lengkap pemetaan file.

/proc/<pid>/smaps_rollup menyediakan agregat RSS dan PSS untuk semua pemetaan dalam suatu proses. Saat memperkirakan jejak fisik yang diatribusikan ke 8 worker, jumlah PSS umumnya lebih berguna daripada jumlah RSS, meskipun persaingan page-cache sistem dan proses yang tidak terkait tetap berpengaruh.

Langkah 6: Verifikasi Bottleneck dengan Observasi yang Dapat Direproduksi

Bangun satu linimasa alih-alih menarik kesimpulan dari satu tangkapan layar top. Di lingkungan pengujian 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 kueri yang sama persis sebanyak dua kali:

1. setelah cold start, catat p50, p95, dan p99 permintaan, delta fault, block read, dan RSS/PSS;
2. ulangi segera dengan data, konkurensi, dan jalur kode yang sama;
3. jika major fault, read I/O, dan tail latency semuanya tinggi pada proses pertama dan jauh lebih rendah pada proses kedua, page file yang dimuat sesuai permintaan (demand-loaded) adalah penjelasan utama yang kuat;
4. jika major fault jarang terjadi sementara latensi tetap tinggi, periksa CPU, lock, remote call, dan inisialisasi indeks internal;
5. ulangi di bawah tekanan memori terkontrol untuk melihat apakah proses reclaim pada page panas memunculkan kembali lonjakan latensi.

Counter fault bersifat kumulatif, jadi bandingkan delta dalam jendela waktu yang sama daripada total seumur hidup. Ukur worker secara terpisah agar fault dari background scanner tidak salah diatribusikan ke permintaan online.

Langkah 7: Pilih Optimasi Berdasarkan Working Set dan SLO

Pilihan yang paling agresif tidak serta merta menjadi yang terbaik:

1. Pertahankan demand paging: startup tercepat dan memori proporsional dengan working set nyata. Ini cocok untuk beban kerja yang mentoleransi cold traffic atau memiliki area panas yang bergeser, dengan konsekuensi latensi first-touch.
2. Hangatkan hanya page panas: jalankan kueri representatif atau sentuh page dari manifes hot-set sebelum readiness. Ini memindahkan biaya terbatas ke waktu lebih awal dan biasanya lebih terkontrol daripada memindai 20 GiB, tetapi definisi hot-set harus dipelihara.
3. Berikan petunjuk akses madvise: MADV_WILLNEED menyatakan bahwa rentang tersebut akan segera dibutuhkan, memungkinkan read-ahead. Pola sekuensial dan acak juga memiliki petunjuk berbeda. Ini adalah petunjuk performa, bukan jaminan residensi.
4. Uji MAP_POPULATE: ini melakukan prefault pada page table dan memicu read-ahead untuk pemetaan file, mengurangi fault pemblokiran di kemudian hari. Trade-off-nya adalah mmap dan startup yang lebih lambat, I/O serta tekanan memori yang terkonsentrasi, dan fakta bahwa populasi yang tidak lengkap tidak selalu menggagalkan pemanggilan fungsi.
5. Tingkatkan tata letak indeks dan ukuran working set: pisahkan metadata panas dari data dingin, tingkatkan lokalitas, dan kurangi akses lintas-page secara acak. Ini lebih tahan lama daripada prefetching membabi buta.
6. Batasi lalu lintas (gate traffic): buka status kesiapan penuh setelah target cakupan hot-set atau tingkat fault tertentu tercapai, dengan batas waktu (timeout) agar node tidak berada dalam status belum siap selamanya.

Huge page dapat mengurangi tekanan TLB, tetapi tidak menghilangkan I/O file atau memperbaiki working set yang dipilih dengan buruk. Evaluasi huge page hanya setelah bukti mengidentifikasi TLB miss sebagai bottleneck utama dan granularitas memori, fragmentasi, serta lingkungan deployment dapat diterima.

Contoh Jawaban Berkualitas Tinggi

“Pertama-tama saya akan mengonfirmasi bahwa area 20 GiB tersebut adalah pemetaan file read-only dan bahwa mmap terjadi sebelum fork. mmap menciptakan hubungan antara rentang alamat virtual dan file; ini tidak membaca seluruh file ke dalam memori fisik. Oleh karena itu, VmSize setiap worker langsung meningkat sekitar 20 GiB, sementara RSS hanya bertambah saat kueri menyentuh page.

Sebuah akses akan memeriksa TLB terlebih dahulu. TLB miss hanya menyatakan bahwa cache translasi terkini tidak memiliki entri tersebut. Jika entri page-table valid, diizinkan, dan residen, page-table walk dan pengisian TLB sudah cukup; tidak ada page fault. Fault hanya terjadi jika status page-table tidak dapat memenuhi akses, seperti page file non-residen, penulisan copy-on-write pertama setelah fork, atau izin ilegal.

Untuk counter Linux, saya mendefinisikan minor sebagai tidak memerlukan I/O disk dan major sebagai memerlukan I/O disk. Setelah cold start, page indeks yang digunakan oleh permintaan pertama mungkin tidak ada di page cache, sehingga membacanya menyebabkan major fault dan tail latency yang lebih tinggi. Mengulangi kueri yang sama akan mengenai page cache, sehingga mungkin hanya menyebabkan minor fault atau menggunakan pemetaan yang ada dan latensi menurun. Major fault tidak terbatas pada swap; pemetaan berbasis file dapat menghasilkannya bahkan pada mesin tanpa swap.

Para worker dapat berbagi page file read-only, tetapi RSS setiap worker menghitung shared page yang dipetakannya. Saya tidak akan menjumlahkan nilai RSS secara langsung. Saya akan memeriksa PSS, RssFile, RssAnon, dan VmPTE di /proc/<pid>/smaps_rollup, lalu menyelaraskannya dengan block read, delta minor dan major fault, serta p99 permintaan dalam jendela waktu 30 detik yang sama.

Untuk verifikasi, saya akan menjalankan set kueri yang sama dua kali. Jika major fault, read I/O, dan p99 tinggi pada proses pertama dan turun bersamaan pada proses kedua, hal itu mendukung pemuatan sesuai permintaan (demand loading) sebagai penyebab utama. Saya kemudian akan mengukur hot working set yang sebenarnya. Jika hanya 2 GiB dari indeks 20 GiB yang panas, saya akan menghangatkan area tersebut sebelum readiness dan menggunakan petunjuk madvise yang sesuai untuk akses sekuensial atau acak. Jika SLO mengizinkan biaya startup yang lebih besar, saya akan menjalankan uji A/B dengan MAP_POPULATE. Saya tidak akan memindai seluruh file secara default atau memperlakukan huge page sebagai perbaikan umum untuk page fault. Keputusan akhir akan membandingkan waktu startup, p99 menit pertama, tingkat major fault, PSS, dan stabilitas setelah reclaim memori.”

Jawaban ini menghubungkan konsep, observasi, dan keputusan ke dalam satu rantai yang dapat diuji. Jika pewawancara mengubah tipe pemetaan, working set, atau SLO kesiapan, kerangka kerja yang sama tetap menghasilkan pilihan berbeda yang dapat dipertanggungjawabkan.

Kesalahan Umum

• Menganggap VIRT sebagai RAM yang sudah dikonsumsi → pemetaan file dapat memesan rentang alamat tanpa membuat setiap page menjadi residen → periksa VmSize, RSS, PSS, dan tipe pemetaan secara bersamaan.
• Menyamakan TLB miss dengan page fault → entri page-table yang valid dan residen hanya memerlukan translasi → jelaskan pencarian TLB, page-table walk, dan kondisi fault secara terpisah.
• Mengklaim setiap page fault membaca disk → hit pada page-cache, anonymous zero page, dan copy-on-write dapat menghasilkan minor fault → gunakan perbedaan I/O minor/major Linux.
• Mengklaim major fault hanya berasal dari swap → page berbasis file yang tidak di-cache juga memerlukan I/O penyimpanan → identifikasi apakah page yang mengalami fault bersifat anonim atau berbasis file.
• Menjumlahkan RSS dari seluruh 8 worker → shared file page dihitung berulang kali → gunakan PSS untuk membagi shared page dan bandingkan RssFile dengan RssAnon.
• Membaca total fault seumur hidup → angka ini tidak membuktikan hubungan dengan jendela permintaan lambat tertentu → bandingkan delta fault, I/O, dan latensi dalam interval yang sama.
• Memindai seluruh 20 GiB saat startup → ini dapat membuang I/O, menunda kesiapan, dan mengusir page yang lebih berguna → ukur hot set dan hangatkan hanya apa yang dibutuhkan SLO.
• Mengasumsikan MADV_WILLNEED atau MAP_POPULATE menghilangkan fault di masa mendatang → yang pertama adalah petunjuk, yang kedua mungkin tidak lengkap, dan page nantinya dapat di-reclaim → uji perilaku cold-start dan tekanan memori.
• Langsung mengaktifkan huge page → langkah ini terutama mengubah cakupan translasi dan granularitas alokasi, bukan I/O file atau kualitas working set → buktikan terlebih dahulu bahwa TLB miss mendominasi.

Pertanyaan Lanjutan dan Jawaban

Pertanyaan Lanjutan 1: Tidak ada swap di mesin tersebut. Mengapa masih ada major page fault?

Major berarti penanganan fault memerlukan I/O disk; sumbernya tidak harus berasal dari swap. Indeks dalam skenario ini berbasis file. Pada akses pertama ke page file yang tidak ada di page cache, kernel harus membacanya dari sistem file, sehingga akses tersebut dapat menghasilkan major fault. Periksa RssFile, jalur yang dipetakan, dan block read daripada hanya memeriksa VmSwap.

Pertanyaan Lanjutan 2: Worker lain sudah membaca page file yang sama. Apa yang terjadi pada akses pertama worker ini?

Page tersebut mungkin sudah ada di page cache sistem sementara worker ini belum memiliki pemetaan page-table untuknya. Membangun pemetaan tersebut biasanya tidak memerlukan I/O disk dan dapat muncul sebagai minor fault. Akses selanjutnya mungkin masih mengalami TLB miss, tetapi jika entri page-table valid, itu bukan page fault.

Pertanyaan Lanjutan 3: Mengapa menulis dalam jumlah kecil setelah fork dapat meningkatkan PSS?

Page privat pada awalnya dapat dibagikan melalui copy-on-write. Pada penulisan pertama, kernel membuat salinan privat untuk worker yang menulis dan memperbarui page table-nya. Shared page menjadi diatribusikan ke satu proses, sehingga PSS meningkat. Fault ini biasanya tidak memerlukan I/O disk, tetapi alokasi dan penyalinan tetap memakan waktu. Indeks read-only harus menghindari penulisan yang tidak disengaja ke pemetaan privat.

Pertanyaan Lanjutan 4: Apa yang terjadi jika aksesnya acak tetapi layanan menggunakan MADV_SEQUENTIAL?

Petunjuk yang tidak cocok dapat memicu read-ahead yang sia-sia, memuat page yang tidak akan digunakan dan meningkatkan I/O. Untuk point lookup acak, uji MADV_RANDOM atau kebijakan default; jika hot set diketahui, prefetching yang terarah lebih disukai. Nilai setiap petunjuk berdasarkan fault, I/O, PSS, dan latensi daripada namanya.

Pertanyaan Lanjutan 5: Kapan MAP_POPULATE tepat digunakan?

Ini layak diuji ketika startup dapat menghabiskan lebih banyak waktu dan I/O, latensi first-touch online harus stabil, dan rentang pemetaan yang akan segera digunakan dapat diprediksi secara wajar. Ini bisa menjadi pemborosan jika pemetaan jauh lebih besar daripada hot set, node sering melakukan scaling, atau tekanan memori akan segera me-reclaim page tersebut. Kegagalan populasi juga tidak selalu menggagalkan mmap, sehingga residensi aktual dan fault berikutnya harus diukur.

Pertanyaan Lanjutan 6: Bagaimana Anda membedakan lonjakan (churn) page-fault dari kebocoran memori nyata?

Kebocoran biasanya menunjukkan memori anonim privat atau objek yang tidak dapat di-reclaim terus bertambah bahkan di bawah lalu lintas yang stabil. Pertumbuhan dalam working set berbasis file lebih terlihat di RssFile dan page cache, serta dapat turun setelah proses reclaim. Bandingkan RssAnon, RssFile, PSS, VmSwap, dan profil heap atau objek, lalu ulangi di bawah lalu lintas stabil dan tekanan memori terkontrol. Pertumbuhan RSS saja tidak dapat membedakan keduanya.