Machine Translated by Google

440 Bab 9 Memori Virtual

misalnya, ketika proses swapped-out dimulai ulang, semua halamannya ada di disk, dan masing-
masing harus dibawa oleh kesalahan halamannya sendiri. Prepaging adalah upaya untuk
mencegah paging awal tingkat tinggi ini. Strateginya adalah membawa ke dalam memori pada
satu waktu semua halaman yang akan dibutuhkan. Beberapa sistem operasi—terutama Solaris—
mempersiapkan bingkai halaman untuk file kecil.
Dalam sistem yang menggunakan model working-set, misalnya, kita dapat menyimpan
daftar halaman dalam working set-nya dengan setiap proses. Jika kita harus menangguhkan
suatu proses (karena menunggu I/O atau kurangnya frame kosong), kita mengingat working set
untuk proses tersebut. Ketika proses akan dilanjutkan (karena I/O telah selesai atau tersedia
cukup banyak frame kosong), kita secara otomatis membawa kembali seluruh rangkaian kerjanya
ke dalam memori sebelum memulai kembali proses.
Prepaging mungkin menawarkan keuntungan dalam beberapa kasus. Pertanyaannya adalah
apakah biaya penggunaan pra-halaman lebih kecil dari biaya servis kesalahan halaman yang
terkait. Mungkin saja banyak halaman yang dibawa kembali ke memori dengan pra-halaman
tidak akan digunakan.
Asumsikan bahwa halaman s sudah dibuat sebelumnya dan sebagian kecil # dari halaman
s ini benar-benar digunakan (0 # 1). Pertanyaannya adalah apakah biaya kesalahan halaman
yang disimpan s* # lebih besar atau lebih kecil dari biaya pra-halaman s* (1 #) halaman yang
tidak perlu. Jika # mendekati 0, pra-halaman akan kalah; jika # mendekati 1, pra-halaman menang.

9.9.2 Ukuran Halaman

Perancang sistem operasi untuk mesin yang ada jarang memiliki pilihan mengenai ukuran
halaman. Namun, ketika mesin baru sedang dirancang, keputusan mengenai ukuran halaman
terbaik harus dibuat. Seperti yang Anda duga, tidak ada satu pun ukuran halaman terbaik.
Sebaliknya, ada seperangkat faktor yang mendukung berbagai ukuran. Ukuran halaman selalu
pangkat 2, umumnya berkisar dari 4.096 (212) hingga 4.194.304 (222) byte.

Bagaimana cara memilih ukuran halaman? Salah satu perhatian adalah ukuran tabel
halaman. Untuk ruang memori virtual yang diberikan, penurunan ukuran halaman meningkatkan
jumlah halaman dan karenanya ukuran tabel halaman. Untuk memori virtual 4 MB (222), misalnya,
akan ada 4.096 halaman 1.024 byte tetapi hanya 512 halaman 8.192 byte. Karena setiap proses
aktif harus memiliki salinan tabel halamannya sendiri, ukuran halaman yang besar diinginkan.

Memori lebih baik digunakan dengan halaman yang lebih kecil, namun. Jika suatu proses
mengalokasikan memori mulai dari lokasi 00000 dan berlanjut sampai memiliki sebanyak yang
dibutuhkan, mungkin tidak akan berakhir tepat pada batas halaman. Dengan demikian, bagian
dari halaman akhir harus dialokasikan (karena halaman adalah unit alokasi) tetapi tidak akan
digunakan (menciptakan fragmentasi internal). Dengan asumsi independensi ukuran proses dan
ukuran halaman, kita dapat mengharapkan bahwa, rata-rata, setengah dari halaman akhir dari
setiap proses akan terbuang sia-sia. Kerugian ini hanya 256 byte untuk halaman 512 byte tetapi
4.096 byte untuk halaman 8.192 byte. Untuk meminimalkan fragmentasi internal, maka, kita
membutuhkan ukuran halaman yang kecil.
Masalah lainnya adalah waktu yang dibutuhkan untuk membaca atau menulis sebuah
halaman. Waktu I/O terdiri dari seek, latency, dan transfer time. Waktu transfer sebanding dengan
jumlah yang ditransfer (yaitu, ukuran halaman)—fakta yang tampaknya bertentangan dengan
ukuran halaman yang kecil. Namun, seperti yang akan kita lihat di Bagian 10.1.1, waktu latency
dan seek time biasanya mengerdilkan waktu transfer. Pada kecepatan transfer 2 MB per detik,
hanya dibutuhkan 0,2 milidetik untuk mentransfer 512 byte. Waktu latency, meskipun, mungkin 8
milidetik, dan mencari waktu 20 milidetik. Dari total waktu I/O
Machine Translated by Google

9.9 Pertimbangan Lain 441

(28,2 milidetik), oleh karena itu, hanya 1 persen yang disebabkan oleh transfer aktual.
Menggandakan ukuran halaman meningkatkan waktu I/O menjadi hanya 28,4 milidetik. Dibutuhkan
28,4 milidetik untuk membaca satu halaman 1.024 byte tetapi 56,4 milidetik untuk membaca jumlah
yang sama dengan dua halaman masing-masing 512 byte. Jadi, keinginan untuk meminimalkan
waktu I/O menuntut ukuran halaman yang lebih besar.
Namun, dengan ukuran halaman yang lebih kecil, total I/O harus dikurangi, karena lokalitas
akan ditingkatkan. Ukuran halaman yang lebih kecil memungkinkan setiap halaman untuk
mencocokkan lokalitas program dengan lebih akurat. Misalnya, pertimbangkan proses berukuran 200
KB , yang hanya setengahnya (100 KB) yang benar-benar digunakan dalam eksekusi. Jika kita hanya
memiliki satu halaman besar, kita harus membawa seluruh halaman, total 200 KB ditransfer dan
dialokasikan. Jika sebaliknya kami memiliki halaman hanya 1 byte, maka kami hanya dapat membawa
100 KB yang benar-benar digunakan, sehingga hanya 100 KB yang ditransfer dan dialokasikan.
Dengan ukuran halaman yang lebih kecil, maka, kami memiliki resolusi yang lebih baik,
memungkinkan kami untuk mengisolasi hanya memori yang benar-benar dibutuhkan. Dengan ukuran
halaman yang lebih besar, kita harus mengalokasikan dan mentransfer tidak hanya apa yang
dibutuhkan tetapi juga hal lain yang kebetulan ada di halaman, baik dibutuhkan atau tidak. Dengan
demikian, ukuran halaman yang lebih kecil akan menghasilkan lebih sedikit I/O dan lebih sedikit total memori yang d
Tetapi apakah Anda memperhatikan bahwa dengan ukuran halaman 1 byte, kami akan memiliki
kesalahan halaman untuk setiap byte? Proses 200 KB yang menggunakan hanya setengah dari
memori itu akan menghasilkan hanya satu kesalahan halaman dengan ukuran halaman 200 KB
tetapi 102.400 kesalahan halaman dengan ukuran halaman 1 byte. Setiap kesalahan halaman
menghasilkan sejumlah besar overhead yang diperlukan untuk memproses interupsi, menyimpan
register, mengganti halaman, antrian untuk perangkat paging, dan memperbarui tabel. Untuk
meminimalkan jumlah kesalahan halaman, kita perlu memiliki ukuran halaman yang besar.
Faktor lain juga harus dipertimbangkan (seperti hubungan antara ukuran halaman dan ukuran
sektor pada perangkat paging). Masalah tidak memiliki jawaban terbaik. Seperti yang telah kita lihat,
beberapa faktor (fragmentasi internal, lokalitas) mendukung ukuran halaman yang kecil, sedangkan
faktor lainnya (ukuran tabel, waktu I/O ) mendukung ukuran halaman yang besar. Namun demikian,
tren historisnya adalah menuju ukuran halaman yang lebih besar, bahkan untuk sistem seluler.
Memang, edisi pertama Konsep Sistem Operasi (1983) menggunakan 4.096 byte sebagai batas atas
pada ukuran halaman, dan nilai ini adalah ukuran halaman yang paling umum pada tahun 1990.
Sistem modern sekarang dapat menggunakan ukuran halaman yang jauh lebih besar, seperti yang
akan kita lihat di bagian berikut.

9.9.3 Jangkauan TLB

Di Bab 8, kami memperkenalkan rasio hit TLB. Ingat bahwa rasio hit untuk TLB mengacu pada
persentase terjemahan alamat virtual yang diselesaikan di TLB daripada tabel halaman. Jelas, rasio
hit terkait dengan jumlah entri di TLB, dan cara untuk meningkatkan rasio hit adalah dengan
meningkatkan jumlah entri di TLB. Namun, ini tidak murah, karena memori asosiatif yang digunakan
untuk membangun TLB mahal dan haus daya.

Terkait dengan rasio hit adalah metrik serupa: TLBreach. Jangkauan TLB mengacu pada
jumlah memori yang dapat diakses dari TLB dan hanya jumlah entri dikalikan dengan ukuran
halaman. Idealnya, set kerja untuk suatu proses disimpan di TLB. Jika tidak, proses akan
menghabiskan banyak waktu untuk menyelesaikan referensi memori di tabel halaman daripada TLB.
Jika kita menggandakan jumlah entri di TLB, kita menggandakan jangkauan TLB . Namun,
Machine Translated by Google

442 Bab 9 Memori Virtual

untuk beberapa aplikasi intensif memori, ini mungkin masih terbukti tidak cukup untuk menyimpan
perangkat kerja.
Pendekatan lain untuk meningkatkan jangkauan TLB adalah dengan meningkatkan ukuran
halaman atau menyediakan beberapa ukuran halaman. Jika kita meningkatkan ukuran halaman —
misalnya, dari 8 KB menjadi 32 KB—kita melipatgandakan jangkauan TLB . Namun, ini dapat
menyebabkan peningkatan fragmentasi untuk beberapa aplikasi yang tidak memerlukan ukuran
halaman yang begitu besar. Atau, sistem operasi mungkin menyediakan beberapa ukuran halaman
yang berbeda. Misalnya, UltraSPARC mendukung ukuran halaman 8 KB, 64 KB, 512 KB, dan 4 MB.
Dari ukuran halaman yang tersedia ini, Solaris menggunakan ukuran halaman 8-KB dan 4-MB . Dan
dengan TLB 64-entry , jangkauan TLB untuk Solaris berkisar dari 512 KB dengan halaman 8-KB
hingga 256 MB dengan halaman 4-MB . Untuk sebagian besar aplikasi, ukuran halaman 8 KB sudah
cukup, meskipun Solaris memetakan 4 MB pertama kode kernel dan data dengan dua halaman 4
MB . Solaris juga memungkinkan aplikasi — seperti database — memanfaatkan ukuran halaman 4
MB yang besar.
Memberikan dukungan untuk beberapa ukuran halaman memerlukan sistem operasi —bukan
perangkat keras—untuk mengelola TLB. Misalnya, salah satu bidang dalam entri TLB harus
menunjukkan ukuran bingkai halaman yang sesuai dengan entri TLB .
Mengelola TLB dalam perangkat lunak dan bukan perangkat keras memerlukan biaya dalam kinerja.
Namun, peningkatan rasio hit dan jangkauan TLB mengimbangi biaya kinerja.
Memang, tren terbaru menunjukkan pergerakan menuju TLB yang dikelola perangkat lunak dan
dukungan sistem operasi untuk beberapa ukuran halaman.

9.9.4 Tabel Halaman Terbalik

Bagian 8.6.3 memperkenalkan konsep tabel halaman terbalik. Tujuan dari bentuk manajemen
halaman ini adalah untuk mengurangi jumlah memori fisik yang diperlukan untuk melacak terjemahan
alamat virtual-ke-fisik. Kami mencapai penghematan ini dengan membuat tabel yang memiliki satu
entri per halaman memori fisik, diindeks oleh pasangan <process-id, page-number>.

Karena mereka menyimpan informasi tentang halaman memori virtual mana yang disimpan di
setiap bingkai fisik, tabel halaman terbalik mengurangi jumlah memori fisik yang diperlukan untuk
menyimpan informasi ini. Namun, tabel halaman terbalik tidak lagi berisi informasi lengkap tentang
ruang alamat logis dari suatu proses, dan informasi itu diperlukan jika halaman yang direferensikan
saat ini tidak ada di memori. Permintaan paging memerlukan informasi ini untuk memproses
kesalahan halaman.
Agar informasi tersedia, tabel halaman eksternal (satu per proses) harus disimpan. Setiap tabel
tersebut terlihat seperti tabel halaman per-proses tradisional dan berisi informasi di mana setiap
halaman virtual berada.
Tetapi apakah tabel halaman eksternal meniadakan kegunaan tabel halaman terbalik? Karena
tabel ini direferensikan hanya ketika terjadi kesalahan halaman, tabel ini tidak perlu tersedia dengan
cepat. Sebaliknya, mereka sendiri masuk dan keluar dari memori seperlunya. Sayangnya, kesalahan
halaman sekarang dapat menyebabkan manajer memori virtual untuk menghasilkan kesalahan
halaman lain karena halaman di tabel halaman eksternal diperlukan untuk menemukan halaman
virtual di penyimpanan cadangan. Kasus khusus ini memerlukan penanganan yang hati-hati di kernel
dan penundaan dalam pemrosesan pencarian halaman.

9.9.5 Struktur Program Paging

permintaan dirancang agar transparan bagi program pengguna. Dalam banyak kasus, pengguna
sama sekali tidak menyadari sifat halaman memori. Di lain
Machine Translated by Google

9.9 Pertimbangan Lain 443

kasus, bagaimanapun, kinerja sistem dapat ditingkatkan jika pengguna (atau kompiler) memiliki
kesadaran tentang paging permintaan yang mendasarinya.
Mari kita lihat contoh yang dibuat-buat tetapi informatif. Asumsikan bahwa halaman
berukuran 128 kata. Pertimbangkan program C yang fungsinya adalah untuk menginisialisasi
ke 0 setiap elemen dari array 128-kali-128. Kode berikut adalah tipikal:

int saya, j;
int[128][128] data;

untuk (j = 0; j < 128; j++)

untuk (i = 0; i < 128; i++) data[i][j] =
0;

Perhatikan bahwa array disimpan baris utama; yaitu, array menyimpan data[0][0], data[0][1],
···, data[0][127], data[1][0], data[1][1] , ···, data[127][127]. Untuk halaman 128 kata, setiap baris
membutuhkan satu halaman. Jadi, kode sebelumnya nol satu kata di setiap halaman, lalu kata
lain di setiap halaman, dan seterusnya. Jika sistem operasi mengalokasikan kurang dari 128
frame ke seluruh program, maka eksekusinya akan menghasilkan 128 × 128 = 16.384
kesalahan halaman.
Sebaliknya, misalkan kita mengubah kode menjadi

int saya, j;
int[128][128] data;

untuk (i = 0; i < 128; i++)

untuk (j = 0; j < 128; j++) data[i][j] =
0;

Kode ini meniadakan semua kata pada satu halaman sebelum memulai halaman berikutnya,
mengurangi jumlah kesalahan halaman menjadi 128.
Pemilihan struktur data dan struktur pemrograman yang cermat dapat meningkatkan
lokalitas dan karenanya menurunkan tingkat kesalahan halaman dan jumlah halaman dalam
set kerja. Misalnya, tumpukan memiliki lokalitas yang baik, karena akses selalu dibuat ke atas.
Tabel hash, sebaliknya, dirancang untuk menyebarkan referensi, menghasilkan lokalitas yang
buruk. Tentu saja, lokalitas referensi hanyalah salah satu ukuran efisiensi penggunaan struktur
data. Faktor berat lainnya termasuk kecepatan pencarian, jumlah referensi memori, dan jumlah
halaman yang disentuh.

Pada tahap selanjutnya, compiler dan loader dapat memiliki pengaruh yang signifikan
pada paging. Memisahkan kode dan data dan menghasilkan kode reentrant berarti bahwa
halaman kode hanya dapat dibaca dan karenanya tidak akan pernah dimodifikasi. Halaman
bersih tidak harus dicabut untuk diganti. Pemuat dapat menghindari penempatan rutinitas
melintasi batas halaman, menjaga setiap rutinitas sepenuhnya dalam satu halaman.
Rutinitas yang saling memanggil berkali-kali bisa dikemas dalam satu halaman yang sama.
Pengemasan ini adalah varian dari masalah pengepakan bin dari riset operasi: cobalah untuk
mengemas segmen beban berukuran variabel ke dalam halaman berukuran tetap sehingga
referensi antar halaman diminimalkan. Pendekatan seperti ini sangat berguna untuk ukuran
halaman yang besar.
Machine Translated by Google

444 Bab 9 Memori Virtual

9.9.6 Interlock I/O dan Penguncian Halaman

Saat permintaan paging digunakan, terkadang kita perlu mengizinkan beberapa halaman
dikunci dalam memori. Salah satu situasi seperti itu terjadi ketika I/O dilakukan ke atau
dari memori pengguna (virtual). I/O sering diimplementasikan oleh prosesor I/O yang terpisah.
Misalnya, pengontrol untuk perangkat penyimpanan USB umumnya diberikan jumlah byte
yang akan ditransfer dan alamat memori untuk buffer (Gambar 9.28). Ketika transfer
selesai, CPU terganggu.
Kita harus yakin bahwa urutan kejadian berikut tidak terjadi: Sebuah proses
mengeluarkan permintaan I/O dan dimasukkan ke dalam antrian untuk perangkat I/O
tersebut . Sedangkan CPU diberikan kepada proses lain. Proses ini menyebabkan
kesalahan halaman, dan salah satunya, menggunakan algoritme penggantian global,
menggantikan halaman yang berisi buffer memori untuk proses menunggu. Halaman-
halamannya di-page out. Beberapa waktu kemudian, ketika permintaan I/O maju ke kepala
antrian perangkat, I/O terjadi ke alamat yang ditentukan. Namun, bingkai ini sekarang
digunakan untuk halaman berbeda milik proses lain.
Ada dua solusi umum untuk masalah ini. Salah satu solusinya adalah jangan pernah
mengeksekusi I/O ke memori pengguna. Sebaliknya, data selalu disalin antara memori
sistem dan memori pengguna. I/O hanya terjadi antara memori sistem dan perangkat I/O .
Untuk menulis blok pada pita, pertama-tama kita menyalin blok ke memori sistem dan
kemudian menulisnya ke pita. Penyalinan ekstra ini dapat mengakibatkan overhead yang
sangat tinggi.
Solusi lain adalah mengizinkan halaman dikunci ke dalam memori. Di sini, bit kunci
dikaitkan dengan setiap frame. Jika bingkai terkunci, bingkai tidak dapat dipilih untuk
diganti. Di bawah pendekatan ini, untuk menulis sebuah blok pada tape, kita mengunci ke
dalam memori halaman-halaman yang berisi blok tersebut. Sistem kemudian dapat
melanjutkan seperti biasa. Halaman yang dikunci tidak dapat diganti. Ketika I/O selesai,
halaman dibuka.

penyangga

disk drive

Gambar 9.28 Alasan mengapa frame yang digunakan untuk I/O harus berada di memori.
Machine Translated by Google

9.10 Contoh Sistem Operasi 445

Bit kunci digunakan dalam berbagai situasi. Seringkali, beberapa atau semua kernel sistem operasi
terkunci ke dalam memori. Banyak sistem operasi tidak dapat mentolerir kesalahan halaman yang
disebabkan oleh kernel atau modul kernel tertentu, termasuk yang melakukan manajemen memori. Proses
pengguna mungkin juga perlu mengunci halaman ke dalam memori. Sebuah proses database mungkin
ingin mengelola sepotong memori, misalnya, memindahkan blok antara disk dan memori itu sendiri karena
ia memiliki pengetahuan terbaik tentang bagaimana ia akan menggunakan datanya. Penyematan halaman
seperti itu dalam memori cukup umum, dan sebagian besar sistem operasi memiliki panggilan sistem yang
memungkinkan aplikasi meminta agar wilayah ruang alamat logisnya disematkan. Perhatikan bahwa fitur
ini dapat disalahgunakan dan dapat menyebabkan tekanan pada algoritme manajemen memori. Oleh
karena itu, sebuah aplikasi seringkali membutuhkan hak istimewa untuk membuat permintaan seperti itu.

Penggunaan lain untuk bit kunci melibatkan penggantian halaman normal. Pertimbangkan urutan
kejadian berikut: Kesalahan proses dengan prioritas rendah. Memilih frame pengganti, sistem paging
membaca halaman yang diperlukan ke dalam memori.
Siap untuk melanjutkan, proses dengan prioritas rendah memasuki antrian siap dan menunggu CPU.
Karena ini adalah proses berprioritas rendah, mungkin tidak dipilih oleh penjadwal CPU untuk sementara
waktu. Sementara proses berprioritas rendah menunggu, proses berprioritas tinggi mengalami kesalahan.
Mencari pengganti, sistem paging melihat halaman yang ada di memori tetapi belum direferensikan atau
dimodifikasi: ini adalah halaman yang baru saja dibawa oleh proses berprioritas rendah. Halaman ini terlihat
seperti pengganti yang sempurna: bersih dan akan tidak perlu ditulis, dan ternyata sudah lama tidak
digunakan.

Apakah proses berprioritas tinggi harus dapat menggantikan proses berprioritas rendah adalah
keputusan kebijakan. Bagaimanapun, kami hanya menunda proses dengan prioritas rendah untuk
kepentingan proses dengan prioritas tinggi. Namun, kami menyia-nyiakan upaya yang dihabiskan untuk
memasukkan halaman untuk proses berprioritas rendah. Jika kami memutuskan untuk mencegah
penggantian halaman yang baru dibawa sampai halaman tersebut dapat digunakan setidaknya sekali,
maka kami dapat menggunakan bit kunci untuk menerapkan mekanisme ini. Saat halaman dipilih untuk
diganti, bit kuncinya diaktifkan. Itu tetap menyala sampai proses kesalahan dikirim lagi.

Menggunakan mata kunci dapat berbahaya: mata kunci dapat dihidupkan tetapi tidak pernah
dimatikan. Jika situasi ini terjadi (karena bug di sistem operasi, misalnya), bingkai yang terkunci menjadi
tidak dapat digunakan. Pada sistem pengguna tunggal, penggunaan penguncian yang berlebihan hanya
akan merugikan pengguna yang melakukan penguncian.
Sistem multiuser harus kurang mempercayai pengguna. Misalnya, Solaris memungkinkan penguncian
"petunjuk", tetapi bebas untuk mengabaikan petunjuk ini jika kumpulan bingkai bebas menjadi terlalu kecil
atau jika proses individu meminta terlalu banyak halaman dikunci dalam memori.

9.10 Contoh Sistem Operasi

Di bagian ini, kami menjelaskan bagaimana Windows dan Solaris mengimplementasikan memori virtual.

9.10.1 Windows
Windows mengimplementasikan memori virtual menggunakan paging permintaan dengan pengelompokan.
Clustering menangani kesalahan halaman dengan membawa tidak hanya halaman yang salah tetapi juga
Machine Translated by Google

446 Bab 9 Memori Virtual

beberapa halaman setelah halaman yang salah. Ketika sebuah proses pertama kali dibuat,
proses tersebut diberikan minimum dan maksimum working-set. Minimum working-set
adalah jumlah halaman minimum yang dijamin oleh proses dalam memori.
Jika memori yang cukup tersedia, suatu proses dapat diberikan halaman sebanyak maksimum
working-setnya. (Dalam beberapa keadaan, suatu proses mungkin diizinkan untuk melebihi
batas maksimum kerja.) Manajer memori virtual memelihara daftar bingkai halaman gratis.
Terkait dengan daftar ini adalah nilai ambang batas yang digunakan untuk menunjukkan
apakah tersedia cukup memori bebas. Jika kesalahan halaman terjadi untuk proses yang
berada di bawah maksimum set kerja, manajer memori virtual mengalokasikan halaman dari
daftar halaman gratis ini. Jika proses yang bekerja pada set maksimumnya menyebabkan
kesalahan halaman, proses tersebut harus memilih halaman untuk penggantian menggunakan
kebijakan penggantian halaman LRU lokal .
Ketika jumlah memori bebas turun di bawah ambang batas, manajer memori virtual
menggunakan taktik yang dikenal sebagai pemangkasan set kerja otomatis untuk
mengembalikan nilai di atas ambang batas. Pemangkasan set kerja otomatis bekerja dengan
mengevaluasi jumlah halaman yang dialokasikan untuk proses. Jika suatu proses telah
mengalokasikan lebih banyak halaman daripada minimum working-set-nya, manajer memori
virtual menghapus halaman-halaman sampai proses mencapai minimum working-set-nya.
Sebuah proses yang berada pada working-set minimumnya dapat dialokasikan halaman dari
daftar free-page-frame setelah memori bebas yang cukup tersedia. Windows melakukan
pemangkasan set kerja pada mode pengguna dan proses sistem.
Memori virtual dibahas dengan sangat rinci dalam studi kasus Windows di Bab 19.

9.10.2 Solaris
Di Solaris, ketika sebuah utas menimbulkan kesalahan halaman, kernel memberikan halaman
ke utas yang salah dari daftar halaman gratis yang dikelolanya. Oleh karena itu, sangat penting
bahwa kernel menyimpan jumlah memori bebas yang cukup. Terkait dengan daftar halaman
gratis ini adalah parameter—lotsfree—yang mewakili ambang batas untuk memulai paging.
Parameter lotsfree biasanya diatur ke 1/64 ukuran memori fisik. Empat kali per detik, kernel
memeriksa apakah jumlah memori bebas kurang dari lotfree. Jika jumlah halaman gratis
berada di bawah lotfree, proses yang dikenal sebagai pageout dimulai. Proses keluar halaman
mirip dengan algoritma kesempatan kedua yang dijelaskan di Bagian 9.4.5.2, kecuali bahwa
menggunakan dua tangan saat memindai halaman, bukan satu.

Proses pageout bekerja sebagai berikut: Jarum depan jam memindai semua halaman
dalam memori, menyetel bit referensi ke 0. Kemudian, jarum belakang jam memeriksa bit
referensi untuk halaman dalam memori, menambahkan setiap halaman yang bit referensinya
masih diatur ke 0 ke daftar gratis dan menulis ke disk isinya jika dimodifikasi. Solaris
menyimpan daftar cache halaman yang telah "dibebaskan" tetapi belum ditimpa. Daftar gratis
berisi bingkai yang memiliki konten tidak valid. Halaman dapat diambil kembali dari daftar
cache jika diakses sebelum dipindahkan ke daftar gratis.

Algoritma pageout menggunakan beberapa parameter untuk mengontrol kecepatan

halaman yang dipindai (dikenal sebagai scanrate). Kecepatan pemindaian dinyatakan dalam
halaman per detik dan berkisar dari pemindaian lambat hingga pemindaian cepat . Ketika
memori bebas turun di bawah banyak bebas, pemindaian terjadi pada halaman pemindaian
lambat per detik dan berlanjut ke pemindaian cepat , tergantung pada jumlah memori bebas yang tersedia.
Nilai default slowscan adalah 100 halaman per detik. Fastscan biasanya
Machine Translated by Google

9.10 Contoh Sistem Operasi 447

set ke nilai (total halaman fisik)/2 halaman per detik, dengan maksimum 8.192
halaman per detik. Ini ditunjukkan pada Gambar 9.29 (dengan fastscan diatur ke
maksimum).
Jarak (dalam halaman) antara jarum jam ditentukan oleh parameter sistem,
handspread. Jumlah waktu antara kliring tangan depan sedikit dan tangan
belakang menyelidiki nilainya tergantung pada scanrate dan handspread. Jika
scanrate adalah 100 halaman per detik dan handspread adalah 1.024 halaman,
10 detik dapat berlalu antara waktu bit yang diatur oleh tangan depan dan waktu
diperiksa oleh tangan belakang. Namun, karena tuntutan ditempatkan pada
sistem memori, scanrate beberapa ribu tidak jarang. Ini berarti bahwa jumlah
waktu antara kliring dan investigasi sedikit sering beberapa detik.

Seperti disebutkan di atas, proses pageout memeriksa memori empat kali

per detik. Namun, jika memori bebas turun di bawah nilai desfree (Gambar 9.29),
pageout akan berjalan seratus kali per detik dengan maksud menjaga setidaknya
memori bebas desfree tersedia. Jika proses pageout tidak dapat mempertahankan
jumlah memori bebas pada desfree selama rata-rata 30 detik, kernel memulai
proses swapping, sehingga membebaskan semua halaman yang dialokasikan
untuk proses swap. Secara umum, kernel mencari proses yang telah menganggur
untuk waktu yang lama. Jika sistem tidak dapat mempertahankan jumlah memori
bebas di minfree, proses pageout dipanggil untuk setiap permintaan halaman
baru.
Rilis terbaru dari kernel Solaris telah memberikan peningkatan algoritma
paging. Salah satu peningkatan tersebut melibatkan pengenalan halaman dari
perpustakaan bersama. Halaman milik perpustakaan yang dibagikan oleh
beberapa proses—bahkan jika memenuhi syarat untuk diklaim oleh pemindai—
dilewati selama proses pemindaian halaman. Kekhawatiran peningkatan lainnya

8192
pemindaian cepat

100

pemindaian lambat

bebas min bebas banyak gratis

jumlah memori bebas

Gambar 9.29 Pemindai halaman Solaris.

Machine Translated by Google

448 Bab 9 Memori Virtual

membedakan halaman yang telah dialokasikan untuk proses dari halaman yang
dialokasikan ke file biasa. Ini dikenal sebagai paging prioritas dan tercakup dalam Bagian 12.6.2.

9.11 Ringkasan

Diinginkan untuk dapat menjalankan proses yang ruang alamat logisnya lebih besar dari
ruang alamat fisik yang tersedia. Memori virtual adalah teknik yang memungkinkan kita
untuk memetakan ruang alamat logis yang besar ke memori fisik yang lebih kecil. Memori
virtual memungkinkan kita untuk menjalankan proses yang sangat besar dan untuk
meningkatkan derajat multiprogramming, meningkatkan pemanfaatan CPU . Lebih lanjut,
ini membebaskan pemrogram aplikasi dari kekhawatiran tentang ketersediaan memori.
Selain itu, dengan memori virtual, beberapa proses dapat berbagi perpustakaan dan
memori sistem. Dengan memori virtual, kita juga dapat menggunakan jenis pembuatan
proses yang efisien yang dikenal sebagai copy-on-write, di mana proses induk dan anak
berbagi halaman memori yang sebenarnya.
Memori virtual biasanya diimplementasikan oleh paging permintaan. Paging permintaan
murni tidak pernah membawa halaman sampai halaman itu direferensikan. Referensi
pertama menyebabkan kesalahan halaman pada sistem operasi. Kernel sistem operasi
berkonsultasi dengan tabel internal untuk menentukan di mana halaman berada di
penyimpanan cadangan. Kemudian menemukan bingkai gratis dan membaca halaman
dari backing store. Tabel halaman diperbarui untuk mencerminkan perubahan ini, dan
instruksi yang menyebabkan kesalahan halaman dimulai ulang. Pendekatan ini
memungkinkan suatu proses untuk berjalan meskipun seluruh citra memorinya tidak
berada di memori utama sekaligus. Selama tingkat kesalahan halaman cukup rendah, kinerja dapat diterim
Kita dapat menggunakan paging permintaan untuk mengurangi jumlah frame yang
dialokasikan untuk suatu proses. Pengaturan ini dapat meningkatkan derajat
multiprogramming (memungkinkan lebih banyak proses tersedia untuk dieksekusi pada
satu waktu) dan—dalam teori, setidaknya—penggunaan CPU dari sistem. Hal ini juga
memungkinkan proses untuk dijalankan meskipun kebutuhan memori mereka melebihi
total memori fisik yang tersedia. Proses tersebut berjalan di memori virtual.
Jika kebutuhan memori total melebihi kapasitas memori fisik, maka mungkin perlu
untuk mengganti halaman dari memori ke bingkai bebas untuk halaman baru. Berbagai
algoritma penggantian halaman digunakan. Penggantian halaman FIFO mudah diprogram
tetapi mengalami anomali Belady. Penggantian halaman yang optimal membutuhkan
pengetahuan di masa mendatang. Penggantian LRU adalah perkiraan penggantian
halaman yang optimal, tetapi bahkan mungkin sulit untuk diterapkan.
Sebagian besar algoritme penggantian halaman, seperti algoritme peluang kedua, adalah
perkiraan penggantian LRU .
Selain algoritme penggantian halaman, diperlukan kebijakan alokasi bingkai. Alokasi
dapat diperbaiki, menyarankan penggantian halaman lokal, atau dinamis, menyarankan
penggantian global. Model working-set mengasumsikan bahwa proses dijalankan di
lokalitas. Set kerja adalah set halaman di lokalitas saat ini. Dengan demikian, setiap proses
harus dialokasikan frame yang cukup untuk set kerjanya saat ini. Jika suatu proses tidak
memiliki cukup memori untuk working set-nya, proses tersebut akan thrash. Menyediakan
frame yang cukup untuk setiap proses untuk menghindari thrashing mungkin memerlukan
proses swapping dan penjadwalan.
Sebagian besar sistem operasi menyediakan fitur untuk file pemetaan memori,
sehingga memungkinkan file I/O diperlakukan sebagai akses memori rutin. Win32 API
mengimplementasikan memori bersama melalui pemetaan memori file.