Pemilihan algoritma penggantian dan aturan alokasi adalah keputusan-keputusan utama yang kita buat untuk sistem pemberian halaman. Masih banyak pertimbangan lain.
Sebuah ciri dari sistem demand-paging adalah adanya page fault yang terjadi saat proses dimulai. Situasi ini adalah hasil dari percobaan untuk mendapatkan tempat pada awalnya. Situasi yang sama mungkin muncul di lain waktu. Saat proses swapped-out dimulai kembali, seluruh halaman ada di disk dan setiap halaman harus dibawa masuk oleh page-fault -nya masing-masing. Sebelum pemberian halaman mencoba untuk mencegah tingkat tinggi dari paging awal. Stateginya adalah untuk membawa seluruh halaman yang akan dibutuhkan pada satu waktu ke memori.
Pada sistem yang menggunakan model working-set , sebagai contoh, kita tetap dengan setiap proses sebuah daftar dari halaman-halaman di working-set -nya. Jika kita harus menunda sebuah proses (karena menunggu I/O atau kekurangan frame bebas), kita mengingat working-set untuk proses itu. Saat proses itu akan melanjutkan kembali (I/O komplit atau frame bebas yang cukup), kita secara otomatis membawa kembali ke memori seluruh working-set sebelum memulai kembali proses tersebut.
Sebelum pemberian halaman bisa unggul di beberapa kasus. Pertanyaan sederhananya adalah apakah biaya untuk menggunakan sebelum pemberian halaman itu lebih rendah daripada biaya melayani page-fault yang berhubungan. Itu mungkin menjadi kasus dimana banyak halaman dibawa kembali ke memori dengan sebelum pemberian halaman tidak digunakan.
Para perancang sistem operasi untuk mesin yang ada kini jarang memiliki pilihan terhadap ukuran halaman. Bagaimana pun, saat mesin-mesin baru sedang dibuat, pemilihan terhadap ukuran halaman terbaik harus dibuat. Seperti yang kau mungkin harapkan, tidak ada sebuah ukuran halaman yang terbaik. Namun, ada himpunan faktor-faktor yang mendukung ukuran-ukuran yang bervariasi. Ukuran-ukuran halaman selalu dengan pangkat 2, secara umum berkisar dari 4.096 (2^12) ke 4.194.304 (2^22) bytes
Bagaimana kita memilih sebuah ukuran halaman? Sebuah perhatian adalah ukuran dari tabel halaman. Untuk sebuah memori virtual dengan ukuran 4 megabytes (2^22), akan ada 4.096 halaman 1.024 bytes, tapi hanya 512 halaman 8.192 bytes. Sebab setiap proses aktif harus memiliki salinan dari tabel halamannya, sebuah halaman yang besar diinginkan.
Di sisi lain, memori lebih baik digunakan dengan halaman yang lebih kecil. Jika sebuah proses dialokasikan di memori mulai dari lokasi 00000, melanjutkan sampai memiliki sebanyak yang dibutuhkan, itu mungkin tidak akan berakhir secara tepat di batas halaman. Kemudian, sebuah bagian dari halaman terakhir harus dialokasikan (sebab halaman-halaman adalah unit-unit dari alokasi) tapi tidak digunakan (pemecahan bagian dalam). Asumsikan ketergantungan antara ukuran proses dan ukuran halaman, kita dapat mengharapkan bahwa, dalam rata-rata, satu-setengah dari halaman terakhir dari setiap proses akan dibuang. Kehilangan ini hanya 256 bytes dari sebuah halaman 512 bytes, tapi akan 4.096 bytes dari halaman 8.192 bytes. Untuk meminimalkan pemecahan bagian dalam, kita membutuhkan ukuran halaman yang kecil.
Masalah lain adalah waktu yang dibutuhkan untuk membaca atau menulis halaman. Waktu I/O terdiri dari mencari, keterlambatan dan waktu pemindahan. Waktu transfer proporsional terhadap jumlah yang dipindahkan (yaitu, ukuran tabel). Sebuah fakta bahwa yang mungkin terasa janggal untuk ukuran tabel yang kecil. Ingat kembali dari Bab 2, bagaimana pun, keterlambatan dan waktu pencarian normalnya membuat waktu pemindahan menjadi kecil. Pada saat laju pemindahan 2 megabytes per detik, hanya menghabiskan 0.2 millidetik untuk memindahkan 512 bytes. Keterlambatan, di sisi lain, kira-kira 8 millidetik dan waktu pencarian 20 millidetik. Dari total waktu I/O (28.2 millidetik), untuk itulah, 1 persen dapat dihubungkan dengan pemindahan sebenarnya. Menggandakan ukuran halaman meningkatkan waktu I/O hingga 28.4 millidetik. Menghabiskan 28.4 millidetik untuk membaca halaman tunggal dari dari 1.024 bytes, tapi 56.4 millidetik untuk jumlah yang sama sebesar dua halaman masing-masing 512 bytes. Kemudian, keinginan untuk meminimalisir waktu I/O untuk ukuran halaman yang lebih besar
Kegunaan dari bentuk manajemen halaman adalah untuk mengurangi jumlah memori fisik yang dibutuhkan untuk melacak penerjemahan alamat virtual-to-physical. Kita menyelesaikan metode penghematan ini dengan membuat tabel yang memiliki hanya satu masukan tiap halaman memori fisik, terdaftar oleh pasangan (pengenal proses, nomor halaman).
Karena mereka tetap menjaga informasi tentang halaman memori virtual yang mana yang disimpan di setiap frame fisik, tabel halaman yang terbalik mengurangi jumlah fisik memori yang dibutuhkan untuk menyimpan informasi ini. Bagaimana pun, tabel halaman yang dibalik tidak lagi mengandung informasi yang lengkap tentang alamat ruang logical dari sebuah proses, dan informasi itu dibutuhkan jika halaman yang direferensikan tidak sedang berada di memori. Demand paging membutuhkan informasi ini untuk memproses page faults. Agar informasi ini tersedia, sebuah tabel halaman luar (satu tiap proses) harus tetap dijaga. Setiap tabel tampak seperti tabel halaman tiap proses tradisional, mengandung informasi dimana setiap halaman virtual berada.
Tetapi, melakukan tabel halaman luar menegasikan kegunaan tabel halaman yang dibalik? Sejak tabel-tabel ini direferensikan hanya saat page fault terjadi, mereka tidak perlu untuk tersedia secara cepat. Namun, mereka masing-masing diberikan atau dikeluarkan halaman dari memori sesuai kebutuhan. Sayangnya, sebuah page fault mungkin sekarang muncul di manager memori virtual menyebabkan halaman lain fault seakan-akan halaman ditabel halaman luar perlu untuk mengalokasikan virtual page di bantuan penyimpanan. Ini merupakan kasus spesial membutuhkan penanganan di kernel dan delay di proses melihat halaman.
Demand paging didesain untuk menjadi transparan kepada program pemakai. Di banyak kasus, pemakai sama sekali tidak mengetahui letak halaman di memori. Di kasus lain, bagaimana pun, kinerja sistem dapat ditingkatkan jika pemakai (atau kompilator) memiliki kesadaran akan demand paging yang mendasar
Pemilihan yang hati-hati dari struktur data dan struktur permograman dapat meningkatkan locality dan karenanya menurunkan laju page fault dan jumlah halaman di himpunan kerja. Sebuah stack memiliki locality yang baik, sejak akses selalu dibuat di atas. Sebuah hash table, di sisi lain, didesain untuk menyebar referensi-referensi, menghasilkan locality yang buruk. Tentunya, referensi akan locality hanyalah satu ukuran dari efisiensi penggunaan struktur data. Faktor-faktor lain yang berbobot berat termasuk kecepatan pencarian, jumlah total dari referensi dan jumlah total dari halaman yang disentuh.
Saat demand paging digunakan, kita terkadang harus mengizinkan beberapa halaman untuk dikunci di memori. Salah satu situasi muncul saat I/O sering diimplementasikan oleh pemroses I/O yang terpisah. Sebagai contoh, sebuah pengendali pita magnetik pada umumnya diberikan sejumlah bytes untuk memindahkan dan sebuah alamat memoro untuk buffer. Saat pemindahan selesai, CPU diinterupsi.
Kita harus meyakinkan urutan dari kejadian-kejadian berikut tidak muncul: Sebuah proses mengeluarkan permintaan I/O, dan diletakkan di antrian untuk I/O tersebut. Sementara itu, CPU diberikan ke proses-proses lain. Proses-proses ini menyebabkan kesalahan penempatan halaman, dan, menggunakan algoritma penggantian global, salah satu dari mereka menggantikan halaman yang mengandung memory buffer untuk proses yang menunggu. Halaman itu dikeluarkan. Kadang-kadang kemudian, saat permintaan I/O bergerak maju menuju ujung dari antrian device, I/O terjadi ke alamat yang telah ditetapkan. Bagaimana pun, frame ini sekarang sedang digunakan untuk halaman berbeda milik proses lain.
Diskusi-diskusi di bab ini telah dikonsentrasikan dalam menyediakan penggunaan yang terbaik secara menyeluruh dari sistem komputer dengan meningkatkan penggunaan memori. Dengan menggunakan memori untuk data yang aktif, dan memindahkan data yang tidak aktif ke disk, kita meningkatkan throughput. Bagaimana pun, proses individual dapat menderita sebagai hasilnya, sebab mereka sekarang dapat menyebabkan page faults tambahan selama eksekusi mereka.
Pertimbangkan sebuah proses atau thread waktu-nyata. Sebuah proses mengharapkan untuk memperoleh kendali CPU, dan untuk menjalankan penyelesaian dengan delay yang minimum. Memori virtual adalah saingan yang tepat untuk perhitungan waktu-nyata, sebab dapat menyebabkan delay jangka panjang, yang tidak diharapkan pada eksekusi sebuah proses saat halaman dibawa ke memori. Untuk itulah, sistem-sistem waktu-nyata hampir tidak memiliki memori virtual.
Pada kasus Solaris 2, para pengembang di Sun Microsystems ingin mengizinkan baik time-sharing dan perhitungan waktu nyata pada sebuah sistem. Untuk memecahkan masalah page-fault, mereka memiliki Solaris 2 mengizinkan sebuah proses untuk memberitahu bagian halaman mana yang penting untuk proses itu. Sebagai tambahan untuk mengizinkan petunjuk-petunjuk akan halaman yang digunakan, sistem operasi mengizinkan pemakai-pemakai yang berhak dapat mengunci halaman yang dibutuhkan di memori. Jika, disalah-gunakan, mekanisme ini dapat mengunci semua proses lain keluar dari sistem. Adalah perlu untuk mengizinkan proses-proses waktu-nyata untuk dapat dibatasi low-dispatch latency