Virtual memory — demand paging, page fault আর copy-on-write

১ · RAM-এর চেয়ে বড় প্রোগ্রাম — virtual memory কেন

আপনার ল্যাপটপে হয়তো ৮ GB RAM. অথচ একসাথে খোলা আছে Chrome-এর বিশটি ট্যাব, VS Code, Zoom আর একটি গেম। Task Manager-এ সবার “মেমরি” যোগ করলে অনেক সময় ৮ GB ছাড়িয়ে যায়, তবু সব চলছে। আবার একটি 64-bit প্রসেস তাত্ত্বিকভাবে ১২৮ TiB (x86-64-এ user অংশ, 4-level page table-এ) পর্যন্ত ঠিকানা ব্যবহার করতে পারে — পৃথিবীর কোনো ল্যাপটপে এত RAM নেই। এই ধাঁধার উত্তর virtual memory.

পর্ব ৩০ থেকে ৩৪-এ দেখেছেন, প্রসেস যে ঠিকানা দেখে (logical বা virtual address) আর RAM-এর আসল ঠিকানা (physical address) আলাদা; মাঝখানে page table অনুবাদ করে, আর TLB সেই অনুবাদ মনে রাখে। এই পর্বের নতুন কথাটি হলো: page table-এর প্রতিটি ঘরে যে RAM-এর frame থাকতেই হবে, এমন কোনো নিয়ম নেই। কিছু page থাকতে পারে ডিস্কে, কিছু হয়তো এখনো তৈরিই হয়নি। প্রসেস সেটা টেরও পায় না — শুধু প্রথম ছোঁয়ায় একটু দেরি হয়।

চারটি বড় লাভ

২ · Demand paging — দরকার পড়লে তবেই আনা

প্রোগ্রাম চালু করার দুটি উপায় ভাবা যায়। এক, পুরো প্রোগ্রামটি ডিস্ক থেকে RAM-এ এনে তারপর চালানো। দুই, কিছুই না এনে চালানো শুরু করা, আর যে page প্রথমবার লাগবে, শুধু সেটিই তখন আনা। দ্বিতীয়টির নাম demand paging — সফটওয়্যারের সাধারণ কৌশল lazy loading-এর মেমরি-রূপ। আধুনিক সব সাধারণ-কাজের OS (Linux, Windows, macOS, Android, iOS) এটিই করে।

চরম রূপটির নাম pure demand paging: exec-এর পর প্রসেসের একটি page-ও RAM-এ থাকে না। CPU প্রথম নির্দেশটি আনতে গেলেই প্রথম page fault. বাস্তবের OS পুরোপুরি “pure” নয় — Linux ফাইল পড়ার সময় আশপাশের কয়েকটি page আগেভাগে পড়ে রাখে (readahead), Windows-এর prefetcher আগের রানের হিসাব দেখে কিছু page আনে। এই আগাম আনার নাম prepaging. তবে মূল নীতি একই: না ছোঁয়া পর্যন্ত আনা নয়।

Valid–invalid bit আর backing store

প্রতিটি page table entry-তে একটি বিট থাকে — valid–invalid bit (x86-এ “present” বিট)। Valid মানে page-টি এই মুহূর্তে একটি frame-এ আছে, ঘরে লেখা frame নম্বর ঠিক। Invalid মানে দুটির একটি:

• ঠিকানাটি বৈধ, কিন্তু page এখন RAM-এ নেই — এটি আছে তার backing store-এ: কোড আর read-only ডেটার জন্য প্রোগ্রামের নিজের ফাইল, সরিয়ে রাখা heap/stack-এর জন্য swap space, অথবা এখনো কখনো ছোঁয়াই হয়নি (তাহলে প্রথম ছোঁয়ায় শূন্য-ভরা নতুন page).
• ঠিকানাটিই অবৈধ — প্রসেসের কোনো এলাকার মধ্যে পড়ে না, যেমন NULL pointer বা মুক্ত করা মেমরি।

হার্ডওয়্যার দুটিকে আলাদা করে না; MMU শুধু দেখে বিটটি 0, আর exception তোলে। পার্থক্য করে kernel — প্রসেসের মেমরি-এলাকার তালিকা দেখে। Linux-এ প্রতিটি এলাকা একটি VMA (virtual memory area); /proc/self/maps-এর প্রতিটি লাইন একটি VMA.

নিচের ডায়াগ্রামে একটি ছোট প্রোগ্রাম report-এর ৬টি virtual page (0 থেকে 5) আর RAM-এ ৪টি খালি frame. “v, F3” মানে valid আর frame 3-এ; “i” মানে invalid. প্রোগ্রাম চলার সাথে সাথে কোন page কখন আসে, খেয়াল করুন:

1exec ./report2fetch first instruction (page 0)3read global counter (page 2)4call: push on stack (page 5)5loop x1000 on pages 0, 2, 56first write to malloc buffer (page 3)7call print_report() (page 1)

৩ · Page fault — ধাপে ধাপে কী ঘটে

“Page fault” নামে ভুল আছে মনে হলেও এটি কোনো ভুল নয় — এটি একটি স্বাভাবিক exception, যার মাধ্যমে হার্ডওয়্যার kernel-কে বলে “এই page-টি নিয়ে কিছু একটা করতে হবে।” একটি সাধারণ Linux ডেস্কটপে প্রতি সেকেন্ডে হাজার হাজার page fault হয়, আর বেশিরভাগই কেউ টেরও পায় না। কিন্তু যে fault-এ ডিস্ক থেকে পড়তে হয়, সেটির ধাপগুলো জানা জরুরি — পরীক্ষায় এটি প্রায় নিশ্চিত প্রশ্ন, আর কর্মক্ষমতা বুঝতেও এটিই ভিত্তি।

নিচে প্রসেস P একটি নির্দেশে ঠিকানা 0x5123 থেকে পড়তে চায়। 4 KiB page-এ এটি page 5, offset 0x123. Page 5 আগে swap-এ সরানো হয়েছিল (swap slot 812):

1MMU: PTE(5).valid == 0  → trap2kernel: 0x5123 inside a VMA? rights ok?3kernel: frame = take(free_list)4kernel: disk read swap[812] → frame5scheduler: run another process6disk interrupt: PTE(5) = frame, valid7P scheduled: restart same instruction8mov eax, [0x5123] completes

Instruction restart — সব নির্দেশ সহজে আবার চালানো যায় না

একটি সাধারণ load নির্দেশ আবার চালানো সহজ — কিছুই বদলায়নি। সমস্যা হয় সেই নির্দেশে, যা কাজের মাঝখানে fault করতে পারে। উদাহরণ: IBM System/360-এর MVC নির্দেশ এক চালেই ২৫৬ বাইট পর্যন্ত কপি করে। উৎস বা গন্তব্য যদি page-সীমা পেরোয়, আর অর্ধেক কপির পরে দ্বিতীয় page-এ fault হয় — আর উৎস ও গন্তব্য যদি একে অপরের ওপর পড়ে — তাহলে উৎসের কিছু অংশ ইতিমধ্যে মুছে গেছে, আবার শুরু করলে ভুল ফল। সমাধান দুটি: (১) নির্দেশ শুরুর আগেই microcode উভয় প্রান্ত ছুঁয়ে দেখে নেয়, fault হলে কিছু বদলানোর আগেই হবে; (২) মুছে যাওয়া মান সাময়িক register-এ রেখে fault হলে ফিরিয়ে দেওয়া। Auto-increment ঠিকানা-পদ্ধতির নির্দেশেও (যা register-এর মান বদলায়) একই সমস্যা। সারকথা: demand paging শুধু OS-এর কৌশল নয়, CPU-কেও নিশ্চিত করতে হয় যে যেকোনো fault-এর পর নির্দেশ নিরাপদে আবার চালানো যায়।

Minor বনাম major fault

উপরের উদাহরণে ডিস্কে যেতে হয়েছে — এটি major (hard) page fault. কিন্তু বেশিরভাগ fault এর চেয়ে অনেক সস্তা, কারণ ডেটা হয় RAM-এ আগে থেকেই আছে, নয়তো দরকারই নেই। এগুলো minor (soft) page fault:

খরচের সংখ্যাগুলো হার্ডওয়্যার আর kernel ভেদে অনেক বদলায় — এগুলো শুধু মাত্রা বোঝানোর জন্য। Linux-এ দুটি গণনাই পাওয়া যায়: ps -o min_flt,maj_flt, /proc/PID/stat, আর C থেকে getrusage()-এর ru_minflt ও ru_majflt. Windows-এর Resource Monitor-এ “Hard Faults/sec” কলামটি major fault-ই দেখায়। এবার নিজের চোখে দেখুন — ১৬ MiB মেমরি নিয়ে প্রতিটি page-এ একবার করে লিখে fault গোনা:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/resource.h>
#include <unistd.h>

static long minor_faults(void) {          /* faults served without disk I/O */
    struct rusage ru;
    getrusage(RUSAGE_SELF, &ru);
    return ru.ru_minflt;
}

int main(void) {
    size_t pg = (size_t)sysconf(_SC_PAGESIZE);
    size_t n = 4096, len = n * pg;              /* 16 MiB with 4 KiB pages */
    long f0 = minor_faults();
    char *p = mmap(NULL, len, PROT_READ | PROT_WRITE,
                   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (p == MAP_FAILED) { perror("mmap"); return 1; }
    madvise(p, len, MADV_NOHUGEPAGE);           /* keep 4 KiB pages */
    long f1 = minor_faults();
    for (size_t i = 0; i < n; i++) p[i * pg] = 1;   /* first touch */
    long f2 = minor_faults();
    for (size_t i = 0; i < n; i++) p[i * pg] = 2;   /* second touch */
    long f3 = minor_faults();

    printf("page size             : %zu bytes\n", pg);
    printf("mmap of %zu MiB        : %ld faults\n", len >> 20, f1 - f0);
    printf("1st touch, %zu pages : %ld faults = %.3f per page\n",
           n, f2 - f1, (double)(f2 - f1) / (double)n);
    printf("2nd touch, same pages : %ld faults\n", f3 - f2);
    munmap(p, len);
    return 0;
}

page size             : 4096 bytes
mmap of 16 MiB        : 0 faults
1st touch, 4096 pages : 4096 faults = 1.000 per page
2nd touch, same pages : 0 faults

৪ · Demand paging-এর খরচ — effective access time-এর হিসাব

প্রতিটি মেমরি-অ্যাক্সেস দুই রকম হতে পারে: page valid (খরচ ma, অর্থাৎ memory access time), অথবা page fault (খরচ পুরো page-fault service time). Page-fault rate p (0 ≤ p ≤ 1) হলে গড় খরচ, অর্থাৎ effective access time:

Page-fault service time-এ তিনটি অংশ: (১) trap সামলানো, (২) page পড়া — হার্ড ডিস্কে seek, ঘূর্ণনের অপেক্ষা আর transfer মিলিয়ে কয়েক মিলিসেকেন্ড, আর victim dirty হলে আগে তাকে লেখা, (৩) প্রসেসকে আবার চালানো। প্রথম আর তৃতীয়টি মাইক্রোসেকেন্ডের; দ্বিতীয়টিই প্রধান। এখানে TLB আর page table-এর নিজের অ্যাক্সেস (পর্ব ৩৩) আলাদা করে ধরা হয়নি — পরীক্ষায় সেটা প্রশ্নে বলা থাকে।

উদাহরণ ১ — ma = 200 ns, service time = 8 ms

প্রথমেই একক মেলান: 8 ms = 8,000,000 ns. তাহলে

EAT = (1 − p) × 200 + p × 8,000,000 = 200 + 7,999,800 × p  (ns)

• p = 1/1000 (হাজারে একটি fault): EAT = 200 + 7,999.8 = 8,199.8 ns ≈ 8.2 µs. মেমরি ৪১ গুণ ধীর! হাজারে একটি শুনতে কম, কিন্তু একটি fault (8 ms) একটি সাধারণ অ্যাক্সেসের (200 ns) চল্লিশ হাজার গুণ সময় খায়।
• সর্বোচ্চ ১০% ধীর মানতে হলে: EAT < 220 ns হতে হবে, অর্থাৎ 200 + 7,999,800 × p < 220 ⇒ 7,999,800 × p < 20 ⇒ p < 20 / 7,999,800 = 1 / 399,990 ≈ 2.5 × 10⁻⁶. অর্থাৎ প্রায় চার লক্ষ অ্যাক্সেসে একটির বেশি fault চলবে না।

উদাহরণ ২ — dirty page সহ (পরীক্ষার পরিচিত ধরন)

ma = 100 ns. খালি frame পাওয়া গেলে বা বাদ দেওয়া page পরিষ্কার হলে service time 8 ms; বাদ দেওয়া page dirty হলে (আগে লিখতে হয়) 20 ms. ৭০% ক্ষেত্রে বাদ দেওয়া page dirty. EAT সর্বোচ্চ 200 ns রাখতে p কত হতে পারে?

1. গড় service time = 0.3 × 8 + 0.7 × 20 = 2.4 + 14 = 16.4 ms = 16,400,000 ns.
2. 200 ≥ (1 − p) × 100 + p × 16,400,000 = 100 + 16,399,900 × p.
3. p ≤ 100 / 16,399,900 = 1 / 163,999 ≈ 6.1 × 10⁻⁶.

এখানে dirty bit-এর গুরুত্ব বোঝা যায়: পরিষ্কার page ফেলে দিলেই চলে (ডিস্কে আগের কপি আছে), dirty page আগে লিখতে হয় — service time আড়াই গুণ।

নিচের simulator একই সূত্রে বিভিন্ন p-এর জন্য EAT আর ধীরতার গুণফল দেখায়, আর তিনটি লক্ষ্যের জন্য p-এর সীমা বের করে — একটি SSD-র (service ≈ 0.1 ms) জন্যও:

// Effective access time with demand paging: EAT = (1 - p) * ma + p * service
const ma = 200;              // memory access time, ns
const service = 8e6;         // page-fault service time: 8 ms = 8,000,000 ns (HDD)
const eat = p => (1 - p) * ma + p * service;

console.log("     p (fault rate) | one fault per |  EAT (ns) | slowdown");
for (const n of [Infinity, 1e6, 399990, 1e5, 1e4, 1e3, 100]) {
  const p = 1 / n;
  console.log(p.toExponential(3).padStart(19) + " | " +
    (n === Infinity ? "never" : n.toLocaleString("en-US")).padStart(13) + " | " +
    eat(p).toFixed(1).padStart(9) + " | " + (eat(p) / ma).toFixed(2).padStart(7) + "x");
}

// Largest p for a given slowdown: (1 - p) * ma + p * service < ma * (1 + s)
// => p < ma * s / (service - ma)
for (const [label, s, svc] of [["10% slower, HDD 8 ms", 0.10, service],
                               [" 1% slower, HDD 8 ms", 0.01, service],
                               ["10% slower, SSD 0.1 ms", 0.10, 1e5]]) {
  const p = ma * s / (svc - ma);
  console.log(label + ": p < " + p.toExponential(4) +
              " = 1 / " + Math.round(1 / p).toLocaleString("en-US"));
}

     p (fault rate) | one fault per |  EAT (ns) | slowdown
           0.000e+0 |         never |     200.0 |    1.00x
           1.000e-6 |     1,000,000 |     208.0 |    1.04x
           2.500e-6 |       399,990 |     220.0 |    1.10x
           1.000e-5 |       100,000 |     280.0 |    1.40x
           1.000e-4 |        10,000 |    1000.0 |    5.00x
           1.000e-3 |         1,000 |    8199.8 |   41.00x
           1.000e-2 |           100 |   80198.0 |  400.99x
10% slower, HDD 8 ms: p < 2.5001e-6 = 1 / 399,990
 1% slower, HDD 8 ms: p < 2.5001e-7 = 1 / 3,999,900
10% slower, SSD 0.1 ms: p < 2.0040e-4 = 1 / 4,990

৫ · Copy-on-write — fork দ্রুত হয় যেভাবে

পর্ব ১০-এ দেখেছেন, fork() parent-এর একটি প্রায় হুবহু কপি বানায়, আর বেশিরভাগ সময় child প্রায় সাথে সাথে exec করে সব ফেলে দেয়। ২ GB-এর একটি প্রসেস fork করতে যদি সত্যিই ২ GB কপি করতে হতো, প্রতিটি shell কমান্ডে সেকেন্ড চলে যেত। সমাধান copy-on-write (COW): fork শুধু page table কপি করে, আর লেখার-যোগ্য private page-গুলো দুই দিকেই শুধু-পড়া করে দেয়। যতক্ষণ কেউ শুধু পড়ে, সবাই একই frame ভাগ করে। কেউ লিখতে গেলে protection fault — kernel তখন শুধু সেই একটি page কপি করে।

নিচের ডায়াগ্রামে দুটি page: A (কোড, সবসময় শুধু-পড়া) আর D (ডেটা, মান 10). R মানে শুধু-পড়া, RW মানে পড়া-লেখা। “refcount” হলো frame-টি কতজনের page table-এ আছে:

1parent: D = 102pid = fork()3child: x = D        (read)4child: D = 99       → write fault5child: write retried on F56parent: D = 11      → write fault

এবার আসল Linux-এ মেপে দেখুন। Parent ৮ MiB (2048টি page) ভরে fork করে; child প্রথমে সব page পড়ে, তারপর সব page-এ লেখে, আর প্রতিবার নিজের minor fault গোনে। শেষে parent যাচাই করে তার ডেটা অক্ষত কি না:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/resource.h>
#include <sys/wait.h>
#include <unistd.h>

static long minor_faults(void) {
    struct rusage ru; getrusage(RUSAGE_SELF, &ru); return ru.ru_minflt;
}

int main(void) {
    size_t pg = (size_t)sysconf(_SC_PAGESIZE), n = 2048;   /* 8 MiB */
    char *buf = mmap(NULL, n * pg, PROT_READ | PROT_WRITE,
                     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (buf == MAP_FAILED) { perror("mmap"); return 1; }
    madvise(buf, n * pg, MADV_NOHUGEPAGE);
    for (size_t i = 0; i < n; i++) buf[i * pg] = 'P';   /* parent fills it */
    fflush(stdout);                                     /* nothing buffered at fork */
    pid_t pid = fork();
    if (pid == 0) {
        long f0 = minor_faults(), sum = 0;
        for (size_t i = 0; i < n; i++) sum += buf[i * pg];  /* read only */
        long f1 = minor_faults();
        for (size_t i = 0; i < n; i++) buf[i * pg] = 'C';   /* now write */
        long f2 = minor_faults();
        printf("child : read  %zu pages -> %ld faults (sum ok: %d)\n", n, f1 - f0, sum == 'P' * (long)n);
        printf("child : write %zu pages -> %ld faults\n", n, f2 - f1);
        fflush(stdout); _exit(0);
    }
    waitpid(pid, NULL, 0);
    size_t still_p = 0;
    for (size_t i = 0; i < n; i++) still_p += (buf[i * pg] == 'P');
    printf("parent: %zu of %zu pages still hold 'P'\n", still_p, n);
    return 0;
}

child : read  2048 pages -> 0 faults (sum ok: 1)
child : write 2048 pages -> 2048 faults
parent: 2048 of 2048 pages still hold 'P'

vfork — COW-এর আগের সমাধান

COW সব হার্ডওয়্যারে সহজ ছিল না। তাই BSD Unix-এ (3.0BSD, ১৯৭০-এর দশকের শেষে) আসে vfork(): child parent-এর মেমরি কপি না করে সরাসরি ব্যবহার করে, আর parent থেমে থাকে যতক্ষণ না child exec বা _exit করে। Page table কপির খরচটুকুও নেই, কিন্তু নিয়ম কঠোর — child কোনো ভ্যারিয়েবল বদলালে সেটা parent-এর মেমরিতেই বদলায়, আর ফাংশন থেকে return করলে parent-এর stack নষ্ট হয়। COW-এর তুলনা:

Zero-fill-on-demand

COW-এর একটি আত্মীয় হলো zero-fill-on-demand: নতুন heap, stack বা BSS-এর page প্রথম লেখার মুহূর্তে একটি খালি frame নিয়ে শূন্য দিয়ে ভরে দেওয়া হয় — যা প্রথম C প্রোগ্রামে দেখেছেন। শূন্য করা বাধ্যতামূলক: frame-টিতে হয়তো আগে অন্য কারও পাসওয়ার্ড ছিল। Linux আরেক ধাপ এগোয়: অছোঁয়া anonymous মেমরি যদি শুধু পড়া হয়, kernel সবার page table-এ একটিমাত্র শেয়ার করা zero page শুধু-পড়া হিসেবে বসায়; লিখলে তবেই আসল frame (আরেকটি fault). তাই Linux-এ “আগে পড়ে পরে লিখলে” page প্রতি সাধারণত দুটি minor fault হয়। Windows-এ এই ধরনের page-কে বলে “demand-zero” page, আর kernel-এর একটি থ্রেড অবসরে খালি frame আগেভাগে শূন্য করে রাখে।

৬ · Memory-mapped file আর anonymous memory

Demand paging-এর যন্ত্রটি তৈরি হয়ে গেলে একটি চমৎকার জিনিস বিনামূল্যে পাওয়া যায়: ফাইলকেও মেমরির মতো ব্যবহার করা। mmap দিয়ে একটি ফাইল map করলে kernel শুধু একটি VMA লেখে — “এই ঠিকানা-পরিসর অমুক ফাইলের অমুক অংশ”। প্রথম ছোঁয়ায় page fault, kernel ফাইলের সেই page এনে দেয়। read() লাগে না, buffer-এ কপি লাগে না। পর্ব ১২-এ দেখেছেন MAP_SHARED দিয়ে দুই প্রসেসের shared memory বানানো যায়; এখানে দেখব ফাইলের দিক থেকে।

ফাইল-ম্যাপিংয়ের আবার দুই রূপ: MAP_PRIVATE — লিখলে COW, নিজের কপি বদলায়, ফাইল অক্ষত (প্রোগ্রামের data অংশ এভাবেই map হয়: global ভ্যারিয়েবল বদলালে executable ফাইল বদলায় না)। আর MAP_SHARED — লেখা সরাসরি ফাইলের page-এ যায়। দুটিই পাশাপাশি দেখুন:

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

static void show(int fd, const char *when) {      /* read() the file itself */
    char buf[64] = {0};
    if (pread(fd, buf, sizeof buf - 1, 0) < 0) perror("pread");
    printf("%-22s file says: %s", when, buf);
}

int main(void) {
    const char *text = "exam on sunday at 10 am\n";
    size_t len = strlen(text);
    int fd = open("notice.txt", O_RDWR | O_CREAT | O_TRUNC, 0600);
    if (fd < 0 || write(fd, text, len) != (ssize_t)len) { perror("setup"); return 1; }
    show(fd, "start:");
    char *pv = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
    char *sh = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (pv == MAP_FAILED || sh == MAP_FAILED) { perror("mmap"); return 1; }
    memcpy(pv + 8, "friday", 6);                 /* private copy only */
    show(fd, "after MAP_PRIVATE:");
    memcpy(sh + 8, "monday", 6);                 /* goes to the page cache */
    if (msync(sh, len, MS_SYNC) != 0) perror("msync");   /* and to disk */
    show(fd, "after MAP_SHARED:");
    printf("private mapping sees  : %.*s", (int)len, pv);

    munmap(pv, len);
    munmap(sh, len);
    close(fd);
    unlink("notice.txt");
    return 0;
}

start:                 file says: exam on sunday at 10 am
after MAP_PRIVATE:     file says: exam on sunday at 10 am
after MAP_SHARED:      file says: exam on monday at 10 am
private mapping sees  : exam on friday at 10 am

Page cache — read আর mmap একই page দেখে

কেন pread সাথে সাথে বদলটি দেখল? কারণ Linux-এ ফাইলের ডেটা RAM-এ থাকে একটি জায়গাতেই — page cache-এ। read() সেখান থেকে কপি করে, আর mmap সেই একই frame সরাসরি page table-এ বসায়। ফলে MAP_SHARED-এ লেখামাত্র যেকোনো read() তা দেখে — msync ছাড়াই। তাহলে msync কেন? দেখার জন্য নয়, টিকিয়ে রাখার জন্য। Dirty page kernel নিজের সময়মতো ডিস্কে লেখে (সাধারণত কয়েক সেকেন্ডের মধ্যে); তার আগে বিদ্যুৎ চলে গেলে বদল হারাবে। msync(MS_SYNC) নিশ্চিত করে লেখা ডিস্কে পৌঁছেছে — ঠিক যেমন write-এর পর fsync. সব Unix-এ read আর mmap-এর এই মিল নিশ্চিত ছিল না (পুরোনো কিছু সিস্টেমে আলাদা buffer cache ছিল), তাই বহনযোগ্য কোডে msync-এর পরেই অন্যের দেখার ওপর ভরসা করুন।

৭ · Free-frame pool, overcommit আর RAM ফুরোলে

Free-frame pool

Page fault সামলাতে খালি frame লাগে, আর fault-এর মুহূর্তে victim খুঁজে তাকে ডিস্কে লেখা ধীর। তাই kernel সবসময় কিছু খালি frame-এর একটি তালিকা — free-frame pool — ভরা রাখার চেষ্টা করে। Linux-এ প্রতিটি মেমরি-zone-এর তিনটি “watermark” আছে (min, low, high): খালি frame low-এর নিচে নামলে kswapd নামের kernel থ্রেড পটভূমিতে page সরিয়ে তালিকা high পর্যন্ত ভরে; min-এর নিচে নামলে মেমরি চাওয়া প্রসেসকে নিজেই সরানোর কাজ করতে হয় (direct reclaim), যা আরও ধীর। Windows-এ একই কাজ হয় free, zeroed আর standby তালিকা দিয়ে।

Overcommit — প্রতিশ্রুতি বেশি, মজুত কম

প্রথম C প্রোগ্রামে mmap-এ ১৬ MiB চেয়ে ০টি frame পেয়েছেন। তাহলে কেউ যদি RAM আর swap মিলিয়ে যা আছে তার চেয়ে বেশি চায়? Linux সাধারণত “হ্যাঁ” বলে — এর নাম overcommit. যুক্তি: বেশিরভাগ প্রোগ্রাম যা চায় তার সবটা কখনো ছোঁয় না (বড় buffer, fork-এর পর COW page যা কখনো লেখা হয় না, thread-এর ৮ MiB stack-এর অল্প অংশ)। Linux-এ নিয়ন্ত্রণ /proc/sys/vm/overcommit_memory (sysctl vm.overcommit_memory) দিয়ে — আচরণ kernel সংস্করণে কিছুটা বদলেছে, তাই সঠিক বিবরণ kernel-এর ডকুমেন্টেশন (Documentation/mm/overcommit-accounting.rst) মিলিয়ে নিন:

Windows ভিন্ন পথে চলে: প্রতিটি “commit” করা বাইটের জন্য RAM বা pagefile-এ জায়গা রাখতে হয়। মোট commit charge commit limit (মোটামুটি RAM + pagefile-এর আকার) ছাড়াতে পারে না, ছাড়ালে VirtualAlloc ব্যর্থ হয় (বা pagefile বড় হয়)। অর্থাৎ Windows প্রতিশ্রুতির হিসাব রাখে, Linux-এর ডিফল্ট আশাবাদী। macOS আর iOS-এ মেমরি চাপের সময় প্রথম ভরসা memory compression — অল্প ব্যবহৃত page RAM-এর ভেতরেই চেপে ছোট করে রাখা (macOS-এ OS X Mavericks, ২০১৩ থেকে); macOS দরকারে /private/var/vm-এ swap ফাইলও বানায়, আর iOS সাধারণত disk swap-এর বদলে অ্যাপ বন্ধ করে দেয়।

RAM সত্যিই ফুরোলে

Overcommit-এর দাম আসে পরে: প্রতিশ্রুত মেমরি একসাথে ছোঁয়া হলে page fault-এর সময় খালি frame নেই। Kernel তখন পরপর চেষ্টা করে:

1. Page cache-এর পরিষ্কার ফাইল page ফেলে দেওয়া — সবচেয়ে সস্তা।
2. Dirty ফাইল page ডিস্কে লিখে ফেলা, আর anonymous page swap-এ পাঠানো। কাকে সরাবে, সেটাই page replacement algorithm — পর্ব ৩৬-এর বিষয়।
3. এতেও না কুলালে, আর বারবার সরানো-আনায় সিস্টেম প্রায় থেমে গেলে (thrashing, পর্ব ৩৭), শেষ উপায় OOM killer: একটি প্রসেস বেছে SIGKILL. Malloc ততক্ষণে বহু আগেই সফল হয়ে ফিরেছিল — তাই Linux-এ malloc-এর NULL পরীক্ষা মেমরি-স্বল্পতা ধরার নির্ভরযোগ্য উপায় নয়। OOM killer কাকে বাছে, oom_score_adj আর cgroup-এর মেমরি-সীমা কীভাবে কাজ করে — পর্ব ৩৮-এ।

৮ · AI-এর যুগে virtual memory

“আমার সার্ভারে মেমরি কম, কী করব?” — AI-কে জিজ্ঞেস করলে দ্রুত একগাদা কমান্ড আসবে, যার কিছু আপনার OS-এর জন্য নয়, কিছু বিপজ্জনক, আর কিছু শুধু পুরোনো ব্লগের প্রতিধ্বনি। Virtual memory-র ক্ষেত্রে বিশেষ সমস্যা হলো, ভুল পরামর্শও অনেক সময় “কাজ করছে” বলে মনে হয় — যতক্ষণ না চাপের মুহূর্তে OOM killer আসে। AI-এর সাধারণ ভুলগুলো:

AI-এর পরামর্শ মানার আগে — চেকলিস্ট

• আগে মেপেছি: free -m, vmstat 1 (si/so কলাম), ps -o min_flt,maj_flt,rss, /proc/meminfo — পরেও একই মাপ নিয়ে তুলনা করেছি
• পরামর্শটি আমার OS আর kernel সংস্করণের জন্য কি না, man page বা kernel-এর Documentation/ মিলিয়েছি
• যেকোনো EAT বা মেমরি-হিসাব নিজে হাতে বা ছোট script-এ আবার করেছি, একক মিলিয়েছি
• sysctl বা swap-এর পরিবর্তন আগে পরীক্ষার মেশিনে, বাস্তবের মতো লোডে চালিয়ে দেখেছি; production-এ সরাসরি নয়
• mmap বা fork-নির্ভর কোডে ছোট পরীক্ষা চালিয়ে আচরণ (COW, MAP_SHARED, msync) নিজের চোখে দেখেছি