Mekanisme alokasi memori dengan sistem Buddy (lihat gambar): 1. Pada awalnya terdapat satu blok memori bebas berukuran 1 MB 2. Proses A dengan ukuran 80 KB memasuki memori tersebut.
3. Karena tidak tersedia blok berukuran 80 KB, maka blok 1MB dipecah menjadi 2 blok 512 KB. Blok-blok pecahan ini disebut buddies. Blok pertama beralamat mulai dari 0 dan blok lainnya mulai alamat 512. Kemudian Blok 512 KB pertama dipecah lagi menjadi dua blok buddies 256 KB. Blok 256 KB pertama dipecah lagi menjadi dua blok buddies 128 KB. Jika blok 128 dipecah lagi menjadi 2 blok buddies 64 KB, maka blok tersebut tidak bisa memenuhi request proses tersebut yang besarnya 80 KB. Oleh karena itu blok yang dialokasikan untuk proses 80 KB tersebut adalah blok pertama yang berukuran sebesar 128 KB.
4. Proses B dengan ukuran 210 KB memasuki memori tersebut. Karena blok pertama sudah dialokasikan untuk proses A, maka dicarilah blok berikutnya yang masih dalam keadaan bebas. Namun karena blok selanjutnya hanya berukuran 128 KB, maka proses tersebut dialokasikan ke blok berikutnya yang berukuran 256 KB.
5. Proses C dengan ukuran 55 KB memasuki memori tersebut. Sama seperti sebelumnya, karena blok pertama sudah dialokasikan, maka dicarilah blok berikutnya yang masih dalam keadaan bebas. Karena blok kedua belum dialokasikan dan masih berukuran 128 KB, maka blok tersebut dipecah lagi menjadi dua blok buddies berukuran 64 KB. Proses C dialokasikan pada blok 64 KB pertama.
6. Kemudian, proses A dibebaskan.
7. Proses D dengan ukuran sebesar 45 KB datang memasuki memori. Karena blok pertama sudah bebas, maka blok pertama dapat dialokasikan. Blok tersebut dipecah lagi menjadi dua blok buddies berukuran 64 KB. Proses D dengan ukuran 45 KB mendapat alokasi memori sebesar 64 KB.
8. Proses C dibebaskan. Dengan sistem buddy, kernel akan melakukan penggabungan dari pasangan blok buddy yang bebas dengan ukuran k ke dalam blok tunggal dengan ukuran 2k. Maka ketika proses C dibebaskan, blok tersebut akan digabung dengan blok bebas di sebelahnya menjadi blok tunggal bebas sebesar 128 KB. Sama juga halnya ketika proses D dan B di-release.
Dilihat dari mekanisme pengelolaan alokasi memorinya sistem buddy mempunyai keunggulan dalam dealokasi memori. Dibandingkan dengan algoritma-algoritma yang mengurutkan blok berdasarkan ukuran, sistem buddy mempunyai keunggulan ketika misalnya ada blok berukuran 2^k dibebaskan, maka manajer memori hanya mencari blok 2^k untuk diperiksa apakah dapat dilakukan penggabungan. Pada algoritma lain yang memungkinkan blok-blok memori dipecah dalam sembarang ukuran, keseluruhan blok harus dicari.
Tapi walaupun proses dealokasi mudah dilakukan. Sistem buddy mempunyai kelemahan, yaitu utilisasi memori sangat tidak efisien. Masalah ini muncul karena semua permintaan dibulatkan ke dalam 2^k terdekat yang dapat memuat. Misal jika ada proses berukuran 35 KB, pengalokasian dilakukan di 64 KB. Maka terdapat 29 KB yang disiakan. Ini disebut fragmentasi internal karena memori yang disiakan adalah internal terhadap segmen-segmen yang dialokasikan.
8.3. Alokasi Slab
Alokasi slab bertujuan untuk mengalokasikan struktur data (object) kernel yang dibutuhkan di memori fisik untuk menjalankan proses tertentu. Alokasi slab menggunakan algoritma slab. Slab dibentuk dari halaman-halaman memori fisik yang berdekatan dan digunakan terutama untuk kegiatan pengalokasian memori fisik. Sebuah cache terdiri dari satu atau lebih slab dan diisi oleh beberapa object. Object itu sendiri merupakan bentuk instansiasi dari struktur data kernel yang direpresentasikan oleh cache yang bersangkutan.
Gambar 8.3. Hubungan antara caches, slab, dan kernel objects
Algoritmanya adalah sebagai berikut:
if (there is an object in the cache) take it (no construction required); else {
allocate a new slab and assign it to a cache; construct the object;}
Jika object yang diperlukan sudah terdapat dalam caches, maka ambil saja object tersebut tanpa harus dibuat ulang. Namun jika object yang dibutuhkan belum ada, alokasikanlah sebuah slab baru, berikan ke dalam caches, lalu buatlah object tersebut.
Keuntungan algoritma slab:
• Tidak terdapatnya fragmentasi pada memori fisik. Dengan alokasi slab, tidak ada lagi masalah fragmentasi karena ketika kernel me-request memori untuk sebuah object, memori yang diberikan
adalah tepat sebesar ukuran object tersebut.
• Kebutuhan memori dapat terpenuhi dengan cepat. Proses pengalokasian dan pembebasan memori bisa memakan banyak waktu. Tapi dengan alokasi slab, ketika object pertama kali dibuat, object tersebut langsung dialokasikan ke dalam caches, lalu setelah object tersebut selesai digunakan,
object tersebut diset statusnya menjadi free dan langsung dikembalikan ke dalam caches,
sehingga ketika object tersebut dibutuhkan lagi, tidak perlu ada penginisialisasian ulang object. Hal ini membuat object tersedia setiap saat kernel membutuhkannya.
8.4. Prepaging
Prepaging merupakan suatu cara untuk mengurangi page fault pada saat proses dimulai. Page fault
terjadi ketika halaman yang dibutuhkan tidak berada dalam memori utama, oleh karena itu strateginya adalah dengan membawa seluruh halaman yang akan dibutuhkan pada satu waktu ke memori.
Prepaging tidak selalu berguna. Prepaging akan berguna bila biaya yang digunakan prepaging lebih
sedikit dari biaya menangani kesalahan halaman yang terjadi, yaitu ketika seluruh halaman yang dibawa terpakai sebagian besar. Namun prepaging juga bisa merugikan, yaitu saat biaya prepaging lebih besar dari biaya menangani kesalahan halaman atau dengan kata lain dari keseluruhan halaman yang dibawa yang terpakai hanya sebagian kecil saja.
8.5. Ukuran Halaman
Pada dasarnya tidak ada ukuran halaman yang paling baik, karena terdapat beberapa faktor yang mempengaruhinya. Salah satu faktornya adalah ukuran page table. Setiap proses yang aktif harus memiliki salinan dari page table-nya. Jadi, alangkah baiknya jika ukuran page table itu kecil. Untuk memperoleh ukuran page table yang kecil, jumlah halaman jangan terlalu banyak. Oleh karena, itu ukuran halaman sebaiknya diperbesar agar jumlah halaman tidak terlalu banyak. Misalnya untuk sebuah memori virtual dengan ukuran 4 megabytes (2^22), akan ada 4.096 halaman berukuran 1.024 bytes, tapi hanya 512 halaman jika ukuran halaman 8.192 bytes.
Di sisi lain, pemanfaatan memori lebih baik dengan halaman yang lebih kecil. Jika sebuah proses dialokasikan di memori, mengambil semua halaman yang dibutuhkannya, mungkin proses tersebut tidak akan berakhir pada batas dari halaman terakhir. Jadi, ada bagian dari halaman terakhir yang tidak digunakan walaupun telah dialokasikan. Asumsikan rata-rata setengah dari halaman terakhir tidak digunakan, maka untuk halaman dengan ukuran 256 bytes hanya akan ada 128 bytes yang terbuang, bandingkan dengan halaman berukuran 8192 bytes, akan ada 4096 bytes yang terbuang. Untuk meminimalkan pemborosan ini, kita membutuhkan ukuran halaman yang kecil.
Masalah lain adalah waktu yang dibutuhkan untuk membaca atau menulis halaman. Waktu M/K terdiri dari waktu pencarian, latency dan transfer. Waktu transfer sebanding dengan jumlah yang dipindahkan yaitu, ukuran halamannya. Sedangkan waktu pencarian dan latency biasanya jauh lebih besar dari waktu transfer. Untuk laju pemindahan 2 MB/s, hanya dihabiskan 0.25 millidetik untuk memindahkan 512 bytes. Waktu latency mungkin sekitar 8 millidetik dan waktu pencarian 20 millidetik. Total waktu M/K 28.25 milidetik. Waktu transfer sebenarnya tidak sampai 1%. Sebagai perbandingan, untuk mentransfer 1024 bytes, dengan ukuran halaman 1024 bytes akan dihabiskan waktu 28.5 milidetik (waktu transfer 0.5 milidetik). Namun dengan halaman berukuran 512 bytes akan terjadi 2 kali transfer 512 bytes dengan masing-masing transfer menghabiskan waktu 28.25 milidetik sehingga total waktu yang dibutuhkan 56.5 milidetik. Kesimpulannya, untuk meminimalisasi waktu M/K dibutuhkan ukuran halaman yang lebih besar.
Pertimbangan lainnya adalah masalah lokalitas. Dengan ukuran halaman yang kecil, total M/K harus dikurangi, sehingga lokalitas akan lebih baik. Misalnya, jika ada proses berukuran 200 KB dimana hanya setengahnya saja yang dipakai (100 KB) dalam pengeksekusian. Jika kita mempunyai ukuran halaman yang besar, misalnya berukuran 200 KB, maka keseluruhan proses tersebut akan ditransfer dan dialokasikan, entah itu dibutuhkan atau tidak. Tapi dengan ukuran halaman yang kecil, misalnya 1 byte, maka kita hanya membawa 100 KB yang diperlukan saja.
Tapi, untuk memperkecil terjadinya page fault sebaiknya ukuran halaman diperbesar. Sebagai
contoh, jika ukuran halaman adalah 1 byte dan ada sebuah proses sebesar 200 KB, dimana hanya setengahnya yang menggunakan memori, akan menghasilkan 102.400 page fault . Sedangkan bila ukuran halaman sebesar 200 KB maka hanya akan terjadi 1 kali page fault . Jadi untuk mengurangi
page fault , dibutuhkan ukuran halaman yang besar.
Masih ada faktor lain yang harus dipertimbangkan (misalnya hubungan antara ukuran halaman dengan ukuran sektor pada peranti pemberian halaman). Sampai saat ini belum ada jawaban yang pasti berapa ukuran halaman yang paling baik. Sebagai acuan, pada 1990, ukuran halaman yang paling banyak dipakai adalah 4096 bytes. Sedangkan sistem modern saat ini menggunakan ukuran halaman yang jauh lebih besar dari itu.
8.6. TLB Reach
TLB reach atau jangkauan TLB adalah jumlah memori yang dapat diakses dari TLB (Translation
Lookaside buffers). Jumlah tersebut merupakan perkalian dari jumlah masukan dengan ukuran
halaman.
Jangkauan memori = (jumlah masukan TLB) x (ukuran halaman)
Jika jumlah masukan dari TLB dilipatgandakan, maka jangkauan TLB juga akan bertambah menjadi dua kali lipat. Idealnya, working set dari sebuah proses disimpan dalam TLB. Jika tidak, maka proses akan menghabiskan waktu yang cukup banyak mengatasi referensi memori di dalam tabel halaman daripada di TLB. Tetapi untuk beberapa aplikasi hal ini masih belum cukup untuk menyimpan working set.
Cara lain untuk meningkatkan jangkauan TLB adalah dengan menambah ukuran halaman. Jika ukuran halaman dijadikan dua kali lipatnya, maka jangkauan TLB juga akan menjadi dua kali lipatnya. Namun hal ini akan meningkatkan fragmentasi untuk aplikasi-aplikasi yang tidak membutuhkan ukuran halaman sebesar itu. Sebagai alternatif, Sistem Operasi dapat menyediakan ukuran halaman yang bervariasi. Sebagai contoh, UltraSparc II menyediakan halaman berukuran 8 KB, 64 KB, 512 KB, dan 4 MB. Sedangkan Solaris 2 hanya menggunakan halaman ukuran 8 KB dan 4 MB.
8.7. Struktur Program
Ketika program berjalan, maka ia akan menjadi suatu proses yang pasti membutuhkan memori. Oleh karena itu, implementasi dari suatu program akan sangat berpengaruh pada bagaimana cara proses tersebut menggunakan memori. Selain itu, pemilihan struktur data dan struktur pemrograman secara cermat juga dapat meningkatkan locality sehingga dapat pula menurunkan tingkat kesalahan halaman dan jumlah halaman di working set. Contoh kasus:
int i,j;
int[128][128] data; /*Assume that pages are 128 words in size*/ for(j=0; j< 128; j++)
for(i = 0; i< 128; i++) /*Program to initialize to 0 data[i][j] = 0; each element of 128x128 array*/