OS-এর চোখে হার্ডওয়্যার — CPU, interrupt, memory hierarchy আর I/O

১ · OS কেন হার্ডওয়্যার জানবে — von Neumann মডেল

পর্ব ০১-এ দেখেছেন, অপারেটিং সিস্টেম কম্পিউটারের ব্যবস্থাপক। কিন্তু ব্যবস্থাপক যদি না জানেন কারখানায় কোন যন্ত্র কী পারে, কোনটি ধীর, কোনটি দ্রুত — তিনি ভালো সিদ্ধান্ত নিতে পারবেন না। OS-এর প্রায় প্রতিটি নকশা আসলে হার্ডওয়্যারের কোনো একটি বৈশিষ্ট্যের উত্তর। Scheduler আছে কারণ CPU একটি সময়ে একটিই নির্দেশ চালায় (প্রতি core-এ)। Virtual memory আছে কারণ RAM সীমিত আর ডিস্ক ধীর। Device driver আছে কারণ প্রতিটি ডিভাইসের ভাষা আলাদা। তাই এই পর্বে আমরা হার্ডওয়্যারকে দেখব একজন OS ডিজাইনারের চোখে — সার্কিট নয়, শুধু সেটুকু যা OS-এর সিদ্ধান্তকে প্রভাবিত করে।

আজকের প্রায় সব সাধারণ কম্পিউটার একটি পুরোনো নকশা মেনে চলে। ১৯৪৫ সালে গণিতবিদ John von Neumann EDVAC নামের একটি কম্পিউটারের খসড়া প্রতিবেদনে (“First Draft of a Report on the EDVAC”) যে কাঠামো বর্ণনা করেন, তাকেই আমরা বলি von Neumann architecture. এর মূল কথা stored-program ধারণা: প্রোগ্রামের নির্দেশ আর ডেটা — দুটোই একই মেমরিতে, একই রকম সংখ্যা হিসেবে রাখা থাকে। নতুন প্রোগ্রাম চালাতে তার বদলানোর দরকার নেই, শুধু মেমরিতে নতুন সংখ্যা লিখলেই হয়। OS নিজেও এভাবেই একটি প্রোগ্রাম, যে অন্য প্রোগ্রামকে মেমরিতে এনে চালায়।

২ · CPU-র ছন্দ — fetch, decode, execute আর register

CPU দেখতে যত জটিলই হোক, তার মূল কাজ একটি চক্র, যা সে সেকেন্ডে শতকোটি বার চালায়। একে বলে fetch–decode–execute cycle:

1. Fetch (আনা): program counter (PC) নামের register-এ লেখা আছে পরের নির্দেশের ঠিকানা। CPU সেই ঠিকানা থেকে নির্দেশটি এনে instruction register-এ (IR) রাখে, আর PC-কে পরের নির্দেশের দিকে এগিয়ে দেয়।
2. Decode (বোঝা): নির্দেশটি কী চায় — যোগ, মেমরি থেকে পড়া, নাকি অন্য ঠিকানায় লাফ (jump)?
3. Execute (চালানো): ALU হিসাব করে, ফল register বা মেমরিতে যায়, দরকার হলে flags বদলায়। তারপর আবার fetch.

নিচের খেলনা-কম্পিউটারে মেমরির ১০০, ১০১, ১০২ ঠিকানায় তিনটি নির্দেশ আছে: ২০০ নম্বর ঘরের মান (7) R1-এ আনা, তার সাথে ২০১ নম্বর ঘরের মান (5) যোগ করা, আর ফলটি ২০২ নম্বর ঘরে রাখা। “পরে” চেপে প্রতিটি register-এর মান খেয়াল করুন:

100LOAD  R1, [200]101ADD   R1, [201]102STORE R1, [202]103...2007      ; data2015      ; data2020      ; result goes here

আসল CPU এর চেয়ে অনেক চালাক। আধুনিক processor pipeline ব্যবহার করে — একটি নির্দেশ execute হওয়ার সময় পরেরটি decode আর তার পরেরটি fetch হয়, ঠিক গার্মেন্টসের সেলাই লাইনের মতো। অনেক CPU একাধিক নির্দেশ একসাথে, এমনকি ক্রম বদলে (out-of-order) চালায়। কিন্তু বাইরে থেকে ফল এমনভাবে দেখায় যেন নির্দেশগুলো একে একে চলেছে। OS ডিজাইনারের জন্য এই “যেন একে একে” চুক্তিটুকুই যথেষ্ট — অন্তত একটি core-এর ভেতরে। (একাধিক core-এ এই চুক্তি দুর্বল হয়ে যায়; সেই গল্প পর্ব ২৩-এ।)

Register — CPU-র পকেট খাতা

Register হলো CPU-র ভেতরের অল্প কয়েকটি ঘর, যেগুলো সবচেয়ে দ্রুত পড়া-লেখা যায়। x86-64-এ সাধারণ কাজের ১৬টি ৬৪-বিটের register আছে; ARM64-এ ৩১টি। OS-এর চোখে চার ধরনের register বিশেষ গুরুত্বপূর্ণ:

কেন এত গুরুত্ব? কারণ একটি চলমান প্রোগ্রামের পুরো “এই মুহূর্ত” লুকিয়ে আছে এই register-গুলোতে। ধরুন OS প্রসেস A থামিয়ে প্রসেস B চালাতে চায়। A-র মেমরি যেখানে আছে সেখানেই থাকবে, কিন্তু register তো একটাই সেট — B চালালে সেগুলো B-র মানে ভরে যাবে। তাই OS প্রথমে A-র সব register তার নিজের খাতায় (process control block, পর্ব ০৮) লিখে রাখে, তারপর B-র আগের মানগুলো register-এ ফিরিয়ে আনে। এই কাজের নাম context switch, যার বিস্তারিত পর্ব ০৯-এ। একটি register ভুল ফেরালেই — বিশেষ করে PC বা SP — প্রোগ্রাম ভুল জায়গায় লাফ দেবে বা crash করবে।

৩ · CPU-র দুই চেহারা — privilege mode আর protection ring

একটি প্রশ্ন ভাবুন: আপনার ফোনে একটি গেম চলছে। গেমটি যদি চায়, সে কি সরাসরি ডিস্কের সব ফাইল মুছে দিতে পারে? বা অন্য অ্যাপের মেমরি পড়ে নিতে পারে? পারে না — আর সেটি কোনো সফটওয়্যারের ভদ্রতার জন্য নয়, হার্ডওয়্যারের একটি নিয়মের জন্য।

আধুনিক CPU অন্তত দুটি অবস্থায় চলতে পারে। User mode-এ সাধারণ প্রোগ্রাম চলে; সেখানে কিছু নির্দেশ নিষিদ্ধ। Kernel mode-এ (supervisor mode-ও বলে) OS-এর kernel চলে, আর সব নির্দেশ ব্যবহার করা যায়। যেসব নির্দেশ শুধু kernel mode-এ চলে, তাদের বলে privileged instruction — যেমন CPU থামানো (x86-এ HLT), interrupt table-এর ঠিকানা বসানো (LIDT), page table বদলানো (CR3 register-এ লেখা), timer সেট করা, অনেক ক্ষেত্রে সরাসরি I/O port-এ লেখা। User mode-এ এমন নির্দেশ চালাতে গেলে CPU নিজেই থেমে যায় আর OS-কে ডাকে (একটি exception — অংশ ৭)। OS সাধারণত তখন প্রোগ্রামটি বন্ধ করে দেয়।

Mode কোথায় লেখা থাকে? একটি register-এর কয়েকটি বিটে। x86-এ এটি current privilege level (CPL), যা ০ থেকে ৩ — চারটি protection ring. Intel ১৯৮২ সালের 80286 প্রসেসরে protected mode-এর সাথে এই চার রিং আনে। মজার ব্যাপার, Linux আর Windows — দুটোই কার্যত শুধু ring 0 আর ring 3 ব্যবহার করে; মাঝের দুটি প্রায় অব্যবহৃত (কেন, তা ভাবনার প্রশ্ন ৪-এ)। ARM-এ নাম exception level: EL0 অ্যাপ, EL1 kernel, EL2 hypervisor, EL3 secure firmware. RISC-V-এ U, S আর M mode.

৪ · Memory hierarchy — দ্রুত-ছোট-দামি থেকে ধীর-বড়-সস্তা

প্রকৌশলীরা চান এমন মেমরি, যা একসাথে অনেক বড়, খুব দ্রুত আর সস্তা। দুঃখের বিষয়, এমন কিছু নেই। দ্রুত মেমরি (যেমন SRAM, যা দিয়ে cache তৈরি) প্রতি বাইটে দামি আর চিপে বেশি জায়গা নেয়; বড় আর সস্তা মেমরি (ডিস্ক) ধীর। তাই কম্পিউটার কয়েক স্তরের একটি সিঁড়ি বানায় — memory hierarchy. ওপরের স্তর ছোট আর দ্রুত, নিচের স্তর বড় আর ধীর। প্রতিটি স্তর তার নিচের স্তরের একটি অংশের কপি রাখে।

নিচের টেবিলের সংখ্যাগুলো আনুমানিক — বহুল প্রচলিত “Latency numbers every programmer should know” ধরনের তালিকা আর প্রসেসর-নির্মাতাদের সাধারণ তথ্য থেকে মাত্রা (order of magnitude) বোঝানোর জন্য। নির্দিষ্ট CPU, ঘড়ির গতি, মাদারবোর্ড আর ডিভাইসভেদে এগুলো কয়েক গুণ পর্যন্ত বদলায়। মুখস্থ করার বিষয় সংখ্যা নয়, অনুপাত: প্রতি ধাপে মোটামুটি দশ গুণ বা তার বেশি পার্থক্য।

“যদি L1 = ১ সেকেন্ড হয়” কলামটি খেয়াল করুন। L1 থেকে একটি মান আনতে যদি এক সেকেন্ড লাগত, RAM থেকে আনতে লাগত দেড় মিনিটের মতো, SSD থেকে প্রায় এক দিন, আর হার্ড ডিস্ক থেকে কয়েক মাস! এই কারণেই OS ডিস্কের ডেটা RAM-এ জমিয়ে রাখে (page cache, পর্ব ৩৮), একটি প্রসেস ডিস্কের জন্য অপেক্ষা করলে CPU অন্য প্রসেসকে দিয়ে দেয় (পর্ব ১৬), আর page fault এত ব্যয়বহুল (পর্ব ৩৫)।

Cache-এর ধারণা — hit, miss আর cache line

Cache হলো একটি দ্রুত স্তর, যা ধীর স্তরের সাম্প্রতিক ব্যবহৃত অংশের কপি রাখে। CPU কোনো ঠিকানা চাইলে আগে cache দেখে। পেয়ে গেলে cache hit — দ্রুত উত্তর। না পেলে cache miss — নিচের স্তর থেকে আনতে হয়, আর আনার সময় কপি cache-এও রেখে দেওয়া হয়, পরের বারের জন্য। মোট অনুরোধের কত ভাগ hit হলো, তা হলো hit ratio.

একটি গুরুত্বপূর্ণ বিস্তারিত: cache একটি একটি বাইট আনে না, আনে একটি নির্দিষ্ট আকারের খণ্ড — cache line. x86-এর প্রায় সব আধুনিক প্রসেসরে এর আকার ৬৪ বাইট (অংশ ৯-এর bash প্রোগ্রামে নিজেই দেখবেন)। অর্থাৎ একটি int (৪ বাইট) পড়লে আশপাশের আরও ১৫টি int বিনামূল্যে cache-এ চলে আসে। পরের অংশে দেখবেন, এই একটি তথ্য প্রোগ্রামের গতি কয়েক গুণ বদলে দিতে পারে।

Caching — শুধু CPU-র ব্যাপার নয়

“দ্রুত জায়গায় ধীর জায়গার কপি রাখা” — এই কৌশলটি কম্পিউটারের প্রতিটি স্তরে আছে। RAM ডিস্কের cache (OS-এর page cache); TLB হলো page table-এর cache (পর্ব ৩৩); ব্রাউজার ওয়েবসাইটের cache রাখে; CDN সারা বিশ্বের ব্যবহারকারীর কাছাকাছি ভিডিওর cache রাখে। প্রতিটি ক্ষেত্রে একই তিনটি প্রশ্ন: কোন জিনিস রাখব, জায়গা ফুরালে কোনটি সরাব (replacement — পর্ব ৩৬), আর মূল কপি বদলালে cache-এর কপি কীভাবে ঠিক রাখব (consistency — অংশ ৯)।

Storage structure — volatile আর non-volatile

হিসাবের দিক থেকে আরেকটি বিভাজন জরুরি। Register, cache আর DRAM হলো volatile — বিদ্যুৎ চলে গেলে সব মুছে যায়। লোডশেডিংয়ে ডেস্কটপ হঠাৎ বন্ধ হলে না-সেভ করা Word ফাইল হারায় এই কারণেই। SSD, HDD, USB ড্রাইভ, ম্যাগনেটিক টেপ হলো non-volatile — ডেটা টিকে থাকে। পাঠ্যবইয়ের পরিভাষায় CPU সরাসরি যা পড়তে পারে (RAM) তা primary storage, ডিস্ক secondary storage, আর ব্যাকআপের টেপ বা অপটিক্যাল ডিস্ক tertiary storage. CPU ডিস্ক থেকে সরাসরি নির্দেশ চালাতে পারে না; আগে RAM-এ আনতে হয় — এই আনা-নেওয়াই OS-এর memory আর file system অংশের অর্ধেক কাজ। কোন ডেটা কখন volatile থেকে non-volatile-এ যাবে, তা ঠিক করাও OS-এর দায়িত্ব; crash-এর পরে ডেটা অক্ষত রাখার কৌশল আসবে পর্ব ৪৪-এ।

৫ · Locality — কেন cache আসলেই কাজ করে

একটি প্রশ্ন স্বাভাবিক: L1 cache মাত্র কয়েক ডজন KB, অথচ প্রোগ্রাম ব্যবহার করে কয়েকশো MB. তাহলে cache-এ hit হয় কীভাবে? উত্তর হলো প্রোগ্রামের একটি স্বভাব — locality of reference. বাস্তবের প্রোগ্রাম মেমরির সব জায়গা সমানভাবে ব্যবহার করে না; একটি সময়ে একটি ছোট অংশে ঘোরাফেরা করে। Locality দুই রকম:

এবার একটি পরীক্ষা। C ভাষায় দুই-মাত্রার array মেমরিতে row-major ক্রমে থাকে: আগে সারি ০-এর সব ঘর পাশাপাশি, তারপর সারি ১-এর সব ঘর, এভাবে। তাই সারি ধরে পড়লে (a[i][0], a[i][1]…) আমরা মেমরিতে পরপর এগোই। কলাম ধরে পড়লে (a[0][j], a[1][j]…) প্রতিবার পুরো একটি সারি পরিমাণ লাফ দিই। নিচে একটি খেলনা-cache দিয়ে দুটি পথ তুলনা করুন: array int a[4][4], একটি cache line-এ ধরে ৪টি int (একটি পুরো সারি), আর cache-এ জায়গা মাত্র ২টি line-এর (জায়গা ফুরালে সবচেয়ে পুরোনো-ব্যবহৃত line সরে — LRU).

খেলনা-উদাহরণ থেকে আসল মেশিনে যাই। নিচের প্রোগ্রাম ৪০৯৬ × ৪০৯৬টি int-এর (৬৪ MB) একটি array দুইভাবে যোগ করে আর সময় মাপে। সময় মাপতে ব্যবহার করা হয়েছে clock_gettime(CLOCK_MONOTONIC) — এমন একটি ঘড়ি যা কখনো পেছনে যায় না। চালিয়ে দেখুন:

#include <stdio.h>
#include <time.h>
#define N 4096
static int a[N][N];                 /* 4096 x 4096 ints = 64 MB */

static double now_ms(void) {
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec * 1e3 + t.tv_nsec / 1e6;
}

int main(void) {
    for (int i = 0; i < N; i++)
        for (int j = 0; j < N; j++)
            a[i][j] = 1;
    long long s1 = 0, s2 = 0;
    double t0 = now_ms();
    for (int i = 0; i < N; i++)     /* row-major: a[i][0], a[i][1], ... */
        for (int j = 0; j < N; j++)
            s1 += a[i][j];
    double t1 = now_ms();
    for (int j = 0; j < N; j++)     /* column-major: a[0][j], a[1][j], ... */
        for (int i = 0; i < N; i++)
            s2 += a[i][j];
    double t2 = now_ms();

    double row = t1 - t0, col = t2 - t1;
    printf("sums equal? %s (%lld)\n", s1 == s2 ? "yes" : "no", s1);
    printf("row-major    : %7.1f ms\n", row);
    printf("column-major : %7.1f ms\n", col);
    printf("faster: %s, about %.1fx\n",
           row < col ? "row-major" : "column-major",
           row < col ? col / row : row / col);
    return 0;
}

sums equal? yes (16777216)
row-major    :    30.4 ms
column-major :   166.8 ms
faster: row-major, about 5.5x

৬ · AMAT আর effective access time — হিসাবের পদ্ধতি

Cache কতটা লাভ দিচ্ছে, তা একটি সংখ্যায় প্রকাশ করা যায়: গড়ে একটি মেমরি-পড়ায় কত সময় লাগে। কম্পিউটার আর্কিটেকচারে একে বলে AMAT (average memory access time):

এখানে hit time হলো cache-এ পেলে কত সময়, miss rate = ১ − hit ratio, আর miss penalty হলো না পেলে নিচের স্তর থেকে আনতে বাড়তি কত সময়। দুই স্তরের cache-এ সূত্রটি নিজের ভেতরে নিজেকে বসায়: L1-এর miss penalty হলো L2-এর AMAT.

এখানে m₂ হলো L2-এর local miss rate — যত অনুরোধ L2 পর্যন্ত পৌঁছায়, তার কত ভাগ সেখানেও মেলে না। আর m₁ × m₂ হলো global miss rate — সব অনুরোধের কত ভাগ শেষ পর্যন্ত RAM-এ যায়। নিচের ছোট simulator-এ ধরা হয়েছে L1 hit = ১ cycle, L2 hit = ১০ cycle, L2-এর local miss rate ২০%, আর RAM থেকে আনতে ১০০ cycle. L1-এর miss rate বদলালে কী হয়, দেখুন:

// Two-level cache: AMAT = L1 hit + L1 miss rate x (L2 hit + L2 miss rate x memory)
const L1_HIT = 1;      // cycles
const L2_HIT = 10;     // cycles
const L2_MISS = 0.20;  // local miss rate of L2 (of the accesses that reach L2)
const MEM = 100;       // cycles to fetch from DRAM

const amat = (m1) => L1_HIT + m1 * (L2_HIT + L2_MISS * MEM);
const noL2 = (m1) => L1_HIT + m1 * MEM;
const f = (x, w) => x.toFixed(2).padStart(w);

console.log('L1 miss | AMAT with L2 | AMAT L1 only | reach RAM');
for (const m1 of [0.01, 0.02, 0.05, 0.10, 0.20]) {
  console.log(
    `${(m1 * 100).toFixed(0).padStart(6)}% | ${f(amat(m1), 8)} cyc | ${f(noL2(m1), 8)} cyc |` +
    ` ${(m1 * L2_MISS * 100).toFixed(1).padStart(5)}%`);
}
const ex = amat(0.05);
console.log(`No cache: every access = ${MEM} cycles`);
console.log(`Example: 1 + 0.05 x (10 + 0.20 x 100) = ${ex.toFixed(2)} cycles`);
console.log(`Speed-up over no cache: ${(MEM / ex).toFixed(0)}x`);

L1 miss | AMAT with L2 | AMAT L1 only | reach RAM
     1% |     1.30 cyc |     2.00 cyc |   0.2%
     2% |     1.60 cyc |     3.00 cyc |   0.4%
     5% |     2.50 cyc |     6.00 cyc |   1.0%
    10% |     4.00 cyc |    11.00 cyc |   2.0%
    20% |     7.00 cyc |    21.00 cyc |   4.0%
No cache: every access = 100 cycles
Example: 1 + 0.05 x (10 + 0.20 x 100) = 2.50 cycles
Speed-up over no cache: 40x

পরীক্ষার হিসাব — effective access time, পুরোটা

বিশ্ববিদ্যালয় আর চাকরির পরীক্ষায় একই ধারণা আসে effective access time (EAT) নামে, hit ratio h দিয়ে। এখানে একটি ফাঁদ আছে: প্রশ্নে miss হলে মোট সময় কীভাবে ধরা হবে, তার দুটি প্রচলিত রীতি।

• রীতি ক (hierarchical / look-through): আগে cache দেখা হয়, না পেলে তারপর মেমরি। miss-এর সময় = T_c + T_m. সূত্র: EAT = h × T_c + (1 − h) × (T_c + T_m), যা সরল করলে T_c + (1 − h) × T_m — হুবহু AMAT-এর সূত্র।
• রীতি খ (simultaneous / look-aside): cache আর মেমরিতে একসাথে খোঁজ শুরু হয়। miss-এর সময় = শুধু T_m. সূত্র: EAT = h × T_c + (1 − h) × T_m.

প্রশ্নে স্পষ্ট বলা না থাকলে কোন রীতি ধরছেন তা লিখে দিন — পরীক্ষকেরা সাধারণত সেটিই দেখতে চান।

পর্ব ৩৩-এ এই একই কাঠামো ফিরে আসবে TLB-র effective access time হিসেবে, আর পর্ব ৩৫-এ page fault-এর হিসাবে, যেখানে miss penalty ন্যানোসেকেন্ড নয়, মিলিসেকেন্ড — ফলে সামান্য fault rate-ও গতি নাটকীয়ভাবে কমিয়ে দেয়।

৭ · Interrupt — হার্ডওয়্যার কীভাবে CPU-কে ডাকে

CPU সেকেন্ডে শতকোটি নির্দেশ চালায়, আর কিবোর্ডে আপনি হয়তো সেকেন্ডে পাঁচটি অক্ষর টাইপ করেন। নেটওয়ার্ক কার্ডে প্যাকেট আসে অনিয়মিত সময়ে, ডিস্ক একটি পড়া শেষ করে কয়েক মাইক্রোসেকেন্ড বা মিলিসেকেন্ড পরে। CPU কীভাবে জানবে কখন কোন ডিভাইস প্রস্তুত? দুটি পথ আছে।

Interrupt vector table আর ISR

প্রতিটি interrupt-এর একটি নম্বর থাকে — vector. বুটের সময় OS মেমরিতে একটি টেবিল সাজায়, যার প্রতিটি ঘরে লেখা থাকে “এই নম্বরের interrupt এলে এই ঠিকানার কোড চালাও।” এটিই interrupt vector table (x86-এ নাম Interrupt Descriptor Table, IDT; সেখানে ২৫৬টি ঘর)। প্রতিটি ঘরের কোডকে বলে interrupt service routine (ISR) বা interrupt handler. টেবিলের ঠিকানা বসানো একটি privileged instruction — তাই কোনো অ্যাপ নিজের কোডকে handler বানিয়ে নিতে পারে না। নিচের ডায়াগ্রামে দেখুন, একটি প্রোগ্রাম চলার মাঝে কিবোর্ডের একটি চাপ এলে ঠিক কী ঘটে। (vector নম্বর আর ঠিকানাগুলো উদাহরণ মাত্র।)

Timer interrupt — OS কেন সবসময় CPU ফিরে পায়

এবার একটি গভীর প্রশ্ন। আপনার প্রোগ্রামে যদি থাকে while (1) { } — এমন একটি লুপ যা কখনো system call করে না, কোনো ডিভাইস ছোঁয় না — তাহলে OS কীভাবে CPU ফিরে পাবে? OS তো নিজেও একটি প্রোগ্রাম; CPU যখন অন্য প্রোগ্রাম চালাচ্ছে, OS-এর কোড তখন চলছেই না!

উত্তর: হার্ডওয়্যারের একটি timer. বুটের সময় OS (kernel mode-এ) একটি timer সেট করে, যা নির্দিষ্ট সময় পরপর interrupt পাঠায় — Linux-এ সাধারণত সেকেন্ডে ১০০ থেকে ১০০০ বার (kernel-এর HZ সেটিং, যা compile-এর সময় ঠিক হয়), Windows-এ ডিফল্ট প্রায় ১৫.৬ ms পরপর। প্রতিটি timer interrupt-এ CPU বাধ্যতামূলকভাবে kernel-এর handler-এ যায়। Handler হিসাব করে, চলমান প্রসেস তার ভাগের সময় (time slice) শেষ করেছে কি না; শেষ হলে scheduler অন্য প্রসেস বেছে নেয়। Timer বদলানো বা বন্ধ করা privileged instruction, তাই কোনো অ্যাপ এটি থামাতে পারে না। এই ব্যবস্থার নাম preemptive multitasking, আর পুরো মডিউল ৩-এর scheduling এর ওপরেই দাঁড়িয়ে।

Interrupt, trap আর exception — পার্থক্য কোথায়

সব “থামিয়ে kernel-এ যাওয়া” এক জিনিস নয়। পার্থক্যটি উৎস আর সময়ে:

পরিভাষা বইভেদে একটু আলাদা — কেউ trap বলতে সব synchronous ঘটনা বোঝান, Intel-এর ম্যানুয়ালে exception-কে আবার fault, trap আর abort-এ ভাগ করা আছে। একটি সূক্ষ্ম তফাত মনে রাখার মতো: fault-এর পরে CPU একই নির্দেশ আবার চালায় (যেমন page fault — OS page এনে দিলে নির্দেশটি এবার সফল হয়, পর্ব ৩৫), আর trap-এর পরে পরের নির্দেশ থেকে চলে। Linux-এ exception প্রায়ই প্রসেসের কাছে একটি signal হয়ে পৌঁছায় — শূন্য দিয়ে ভাগে SIGFPE, ভুল মেমরিতে SIGSEGV (পর্ব ১৩); Windows-এ একই ঘটনা structured exception হিসেবে আসে।

৮ · I/O ডিভাইস — controller, device register, port I/O আর DMA

CPU সরাসরি ডিস্কের চাকতি ঘোরায় না, Wi-Fi-র রেডিও তরঙ্গও বোঝে না। প্রতিটি ডিভাইসের সাথে থাকে একটি ছোট নিজস্ব কম্পিউটার — device controller (SSD-র controller, নেটওয়ার্ক কার্ডের চিপ, USB host controller). Controller-এর নিজস্ব buffer আর কয়েকটি device register থাকে, সাধারণত:

• Status register — ডিভাইস ব্যস্ত, প্রস্তুত, নাকি কোনো ত্রুটি হয়েছে।
• Command / control register — CPU এখানে লিখে আদেশ দেয়: “ব্লক ৫০০ পড়ো।”
• Data register (বা buffer) — আদান-প্রদানের ডেটা।

OS-এর ভেতরে যে কোডটি একটি নির্দিষ্ট controller-এর register-এর ভাষা জানে, সেটিই device driver (পর্ব ৩৯)। কিন্তু CPU এই register-এ পৌঁছায় কীভাবে? দুটি পদ্ধতি আছে:

MMIO-তে একটি সতর্কতা আছে: ডিভাইসের register সাধারণ মেমরির মতো আচরণ করে না — একই ঠিকানা দুবার পড়লে দুটি আলাদা মান আসতে পারে (status বদলে গেছে)। তাই এই ঠিকানাগুলো cache-এ রাখা হয় না, আর C-তে driver লেখার সময় compiler যেন পড়া-লেখা বাদ না দেয়, সেজন্য volatile ব্যবহার করা হয়।

DMA — CPU-কে কুলির কাজ থেকে মুক্তি

কিবোর্ডের এক বাইটের জন্য interrupt ঠিক আছে। কিন্তু ডিস্ক থেকে ৪ KB বা নেটওয়ার্ক থেকে মেগাবাইটের পর মেগাবাইট ডেটা আনতে হলে? CPU যদি প্রতিটি শব্দ (word) controller-এর data register থেকে পড়ে RAM-এ লেখে — একে বলে programmed I/O — তাহলে দ্রুততম অংশটি দিনভর কুলির কাজ করবে। সমাধান DMA (direct memory access): একটি আলাদা DMA engine (অনেক সময় ডিভাইসের controller-এর ভেতরেই) CPU-কে না জড়িয়ে সরাসরি ডিভাইস আর RAM-এর মধ্যে ডেটা সরায়। CPU শুধু শুরুতে কাজটি বুঝিয়ে দেয়, আর শেষে একটি interrupt পায়। নিচে দুটি পথ পাশাপাশি:

৯ · একাধিক core — multicore, SMP, hyper-threading আর cache coherence

প্রায় ২০০৫ সালের কাছাকাছি সময়ে চিপ-নির্মাতারা একটি দেয়ালে ঠেকে যান: ঘড়ির গতি (GHz) আর বাড়ানো যাচ্ছিল না, কারণ তাপ আর বিদ্যুৎ-খরচ সামলানো অসম্ভব হয়ে উঠছিল। তাই তাঁরা পথ বদলান — একটি চিপে একাধিক সম্পূর্ণ CPU বসানো। প্রতিটির নাম core, আর এমন চিপ multicore. আজ অনেক কম দামের স্মার্টফোনেও ৮টি core থাকে।

OS-এর চোখে প্রায় সব সাধারণ multicore কম্পিউটার SMP (symmetric multiprocessing): সব core সমান, সবাই একই RAM দেখে, যেকোনো core kernel চালাতে পারে, যেকোনো প্রসেস যেকোনো core-এ চলতে পারে। এতে OS-এর কাজ বাড়ে: প্রতিটি core-এর জন্য আলাদা run queue, প্রসেসকে কোন core-এ রাখলে তার cache গরম থাকে (affinity, পর্ব ২০), আর দুটি core একসাথে kernel-এর একই ডেটা বদলাতে গেলে lock (মডিউল ৪)। বড় সার্ভারে আরেকটি বৈশিষ্ট্য যোগ হয় — NUMA: প্রতিটি CPU socket-এর নিজের কাছের RAM দ্রুত, অন্য socket-এর RAM তুলনামূলক ধীর; OS তাই প্রসেসের মেমরি তার কাছের RAM-এ রাখতে চেষ্টা করে।

Hyper-threading (সাধারণ নাম SMT, simultaneous multithreading) আরেকটু ভিন্ন জিনিস। এখানে একটি physical core-এর ভেতরে দুই সেট register থাকে, ফলে OS-এর কাছে একটি core দুটি “logical CPU” হিসেবে দেখায়। কিন্তু ALU, cache-এর মতো আসল কাজের অংশ দুই থ্রেড ভাগ করে নেয়। একটি থ্রেড মেমরির জন্য অপেক্ষা করলে অন্যটি সেই ফাঁকা সময় কাজে লাগায়। Intel ২০০২ সালে Xeon প্রসেসরে Hyper-Threading নামে এটি আনে; AMD-র Zen প্রসেসরেও (২০১৭ থেকে) SMT আছে। লাভ কাজভেদে সাধারণত দুই গুণের অনেক কম — দুটি logical CPU মানে দুটি পূর্ণ core নয়।

Cache coherence — দুই core, একই ঠিকানা

প্রতিটি core-এর নিজস্ব L1 আর L2 cache আছে। ধরুন একটি ভ্যারিয়েবল x = 5 দুই core-এর cache-এই কপি হয়ে আছে। Core 0 লিখল x = 6. Core 1 এখন x পড়লে পুরোনো 5 পাবে? তা হলে প্রোগ্রাম ভুল চলবে। এই সমস্যার সমাধান cache coherence: হার্ডওয়্যার একটি protocol চালায় (সবচেয়ে পরিচিত MESI — Modified, Exclusive, Shared, Invalid), যাতে কোনো core একটি line-এ লেখার আগে অন্য সব core-এর কপি বাতিল (invalidate) হয়। ফলে Core 1 পরের বার পড়লে miss হবে আর নতুন মান 6 পাবে।

এটি নিজে থেকেই হয়, তবে বিনামূল্যে নয়। দুটি core যদি একই cache line-এর দুটি আলাদা ভ্যারিয়েবলে বারবার লেখে, line-টি দুই cache-এর মধ্যে ক্রমাগত ছোটাছুটি করে — একে বলে false sharing, আর এটি multithreaded প্রোগ্রামকে রহস্যজনকভাবে ধীর করে দেয়। আরও সূক্ষ্ম বিষয় হলো, coherence শুধু “একটি ঠিকানার” মান মেলায়; ভিন্ন ঠিকানায় লেখা অন্য core কোন ক্রমে দেখবে, তা ঠিক করে memory ordering, যার আলোচনা পর্ব ২৩-এ।

আপনার (বা অনলাইন সার্ভারের) CPU সম্পর্কে Linux কী জানে, দেখুন। Linux এই তথ্য দেখায় দুটি ভার্চুয়াল ফাইল-ব্যবস্থায়: /proc/cpuinfo আর /sys/devices/system/cpu/. নিচের script কোনো ফাইল না পেলে ভেঙে না পড়ে বার্তা দেয়:

echo "== CPU =="
grep -m1 'model name' /proc/cpuinfo || echo "(model name not listed)"
echo "logical CPUs we may use: $(nproc)"
flags=$(grep -m1 -E '^(flags|Features)' /proc/cpuinfo | cut -d: -f2)
echo "feature flags: $(echo $flags | wc -w)"
for f in lm nx ht sse2 avx2 vmx svm; do
  if echo " $flags " | grep -qw "$f"; then echo "  $f : yes"; else echo "  $f : no"; fi
done

echo "== cache of cpu0 =="
found=0
for d in /sys/devices/system/cpu/cpu0/cache/index*; do
  [ -r "$d/size" ] || continue
  found=1
  echo "  L$(cat "$d/level") $(cat "$d/type"): $(cat "$d/size")"
done
[ "$found" -eq 1 ] || echo "  (cache info is not exposed here)"
line=$(cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size 2>/dev/null)
echo "cache line: ${line:-unknown} bytes"

== CPU ==
model name	: AMD EPYC-Rome Processor
logical CPUs we may use: 2
feature flags: 80
  lm : yes
  nx : yes
  ht : yes
  sse2 : yes
  avx2 : yes
  vmx : no
  svm : no
== cache of cpu0 ==
  L1 Data: 32K
  L1 Instruction: 32K
  L2 Unified: 512K
  L3 Unified: 16384K
cache line: 64 bytes

অন্য OS-এ একই তথ্য অন্য পথে পাওয়া যায় — /proc শুধু Linux-এর জিনিস:

lscpu                     # সংক্ষিপ্ত সারাংশ: core, thread, cache, NUMA
cat /proc/interrupts      # কোন interrupt কতবার এসেছে, প্রতিটি CPU-তে আলাদা

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, L2CacheSize, L3CacheSize

sysctl -n machdep.cpu.brand_string
sysctl hw.ncpu hw.l1dcachesize hw.l2cachesize hw.cachelinesize

১০ · AI-এর যুগে — হার্ডওয়্যার-প্রশ্নে AI-কে কীভাবে ব্যবহার করবেন

“আমার সার্ভারের L3 cache কত?”, “এই লুপ ধীর কেন?”, “EAT-এর এই অঙ্কটা করে দাও” — এমন প্রশ্নে AI দ্রুত উত্তর দেয়। কিন্তু হার্ডওয়্যারের প্রশ্নে AI-এর ভুলগুলো একটি নির্দিষ্ট ধাঁচের, আর সেগুলো চেনা থাকলে যাচাই সহজ:

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কমান্ডটি আমার OS-এর জন্যই কি না দেখেছি (Linux, Windows, macOS — আর distro-র version)
• কোনো সংখ্যা (latency, cache-আকার) নিজের মেশিনে মেপে বা lscpu/sysctl দিয়ে মিলিয়েছি
• EAT/AMAT-এর অঙ্ক নিজে হাতে করেছি, কোন রীতি ধরা হয়েছে তা লিখেছি
• পারফরম্যান্সের দাবি একবার নয়, কয়েকবার চালিয়ে দেখেছি — একবারের সময় মাপা বিভ্রান্তিকর
• sudo বা kernel-সেটিং বদলানোর পরামর্শ পেলে আগে বুঝেছি সেটি কী করে, আর পরীক্ষামূলক মেশিনে চালিয়েছি