I/O system — polling, interrupt, DMA আর device driver

১ · I/O হার্ডওয়্যারের এক ঝলক — bus, port, controller আর PCIe

পর্ব ০৪-এ (OS-এর চোখে হার্ডওয়্যার) আপনি দেখেছেন: প্রতিটি ডিভাইসের সাথে একটি device controller থাকে, যার status, command আর data নামের কয়েকটি device register আছে। CPU সেগুলো ছোঁয় দুইভাবে — port-mapped I/O (x86-এর in/out) অথবা memory-mapped I/O. সেখানে interrupt আর DMA-র মূল ধারণাও এসেছে। এই পর্ব সেখান থেকে শুরু করে এক ধাপ নিচে নামবে।

PCIe — আধুনিক যন্ত্রের করিডোর

আজকের ল্যাপটপ আর সার্ভারে প্রায় সব দ্রুত ডিভাইস — NVMe SSD, GPU, নেটওয়ার্ক কার্ড, Wi-Fi — বসে PCIe (PCI Express)-এ। পুরোনো PCI ছিল সবার ভাগের একটি সমান্তরাল bus; PCIe হলো point-to-point সিরিয়াল সংযোগ, যার প্রতিটি “lane” আলাদা জোড়া তারে দুই দিকে একসাথে ডেটা পাঠায়। একটি ডিভাইস x1, x4 বা x16 lane পেতে পারে। প্রতি lane-এ মোটামুটি গতি: Gen3-এ প্রায় ১ GB/s, Gen4-এ প্রায় ২ GB/s, Gen5-এ প্রায় ৪ GB/s (প্রতি দিকে). তাই একটি Gen4 x4 NVMe SSD তাত্ত্বিকভাবে প্রায় ৮ GB/s পর্যন্ত যেতে পারে।

বুটের সময় firmware আর OS প্রতিটি PCIe ডিভাইসের configuration space পড়ে জানে কোন নির্মাতা, কোন ধরন, কতটা register-এর জায়গা লাগবে; তারপর physical ঠিকানার একটি অংশ দেয়, যা লেখা থাকে ডিভাইসের BAR (Base Address Register)-এ। এরপর থেকে ওই ঠিকানায় load/store মানেই ডিভাইসের register পড়া-লেখা। Linux-এ lspci -v দিয়ে এটি দেখা যায়:

$ lspci -v -s 01:00.0
01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller
        Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
        Memory at fb000000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
        Kernel driver in use: nvme

চারটি লাইন চারটি গল্প বলে: bus master মানে ডিভাইসটি নিজে DMA করতে পারে (অংশ ৪), Memory at fb000000 … size=16K হলো BAR — ১৬ KiB-এর register এলাকা, MSI-X … Count=33 মানে ৩৩টি আলাদা interrupt vector পাঠাতে পারে (অংশ ৩), আর nvme নামের driver এটি চালাচ্ছে (অংশ ৮)। Windows-এ একই তথ্য Device Manager-এর Properties → Resources ট্যাবে দেখায়।

একই kernel-কে সেকেন্ডে পাঁচটি কী-চাপ আর কয়েক কোটি প্যাকেট — দুটোই সামলাতে হয়; এটিই I/O subsystem-এর মূল সমস্যা।

২ · Polling-এর handshake — busy আর command-ready বিট

সবচেয়ে সরল কথোপকথন দিয়ে শুরু করা যাক: CPU একটি controller-এ একটি বাইট লিখবে (যেমন একটি সিরিয়াল পোর্টে). Controller-এর status register-এ একটি busy বিট আছে — controller কাজ করার সময় সেটি ১. Command register-এ আছে একটি write বিট (আদেশটি লেখা না পড়া) আর একটি command-ready বিট — CPU যখন আদেশ সাজিয়ে প্রস্তুত, তখন সেটি ১ করে। দুই পক্ষ এই বিটগুলো দিয়ে পালাক্রমে কথা বলে — একে বলে handshake. নিচের stepper-এ CPU একটি বাইট 0x41 ('A') লিখছে:

কোডে লুপটি আসলে তিনটি নির্দেশ: status পড়া, busy বিট আলাদা করা (AND), আর ১ হলে আবার শুরুতে লাফ। ডিভাইস দ্রুত হলে লুপ এক-দুবারেই শেষ — তখন polling দারুণ দক্ষ। ডিভাইস ধীর হলে লুপ লাখবার ঘোরে। মাঝামাঝি একটি কৌশল আছে: অল্প কিছুক্ষণ poll করে না পেলে ঘুমিয়ে interrupt-এর অপেক্ষা।

#define BUSY      0x01   /* status register bit */
#define CMD_WRITE 0x01   /* command register bits */
#define CMD_READY 0x80

void put_byte(volatile uint8_t *status, volatile uint8_t *cmd,
              volatile uint8_t *data_out, uint8_t b)
{
    while (*status & BUSY)          /* step 1: busy-wait */
        cpu_relax();                /* x86 "pause": spin politely */
    *data_out = b;                  /* step 2: data first */
    *cmd = CMD_WRITE;
    *cmd = CMD_WRITE | CMD_READY;   /* step 3: then ring the bell */
}

volatile না দিলে compiler একবার পড়েই চিরকালের লুপ বানাতে পারত — পর্ব ০৪-এর MMIO সতর্কতা।

কখন polling interrupt-কে হারায়

প্রতিটি interrupt-এর একটি স্থির দাম আছে: state রাখা, kernel-এ ঢোকা, handler, ফেরা, আর cache নষ্ট হওয়া। ধরা যাক এই দাম ৪ µs (উদাহরণ মাত্র; যন্ত্রভেদে এক থেকে কয়েক µs). তাহলে:

• সেকেন্ডে ১০,০০০ ঘটনা → ১০,০০০ × ৪ µs = ৪০ ms, অর্থাৎ একটি core-এর ৪% — interrupt সস্তা, polling-এ একটি পুরো core নষ্ট হতো।
• সেকেন্ডে ২,৫০,০০০ ঘটনা → ২,৫০,০০০ × ৪ µs = ১ সেকেন্ড, অর্থাৎ ১০০% — শুধু interrupt সামলাতেই একটি core শেষ। এর ওপরে interrupt আর টিকতেই পারে না (অংশ ৩-এর livelock).

দ্বিতীয় কারণ দেরি (latency). একটি আধুনিক NVMe SSD একটি ৪ KiB পড়া মোটামুটি ১০ µs-এর ঘরে শেষ করতে পারে। Interrupt-এর পর ঘুমন্ত thread-কে জাগিয়ে context switch করাতে কয়েক µs লাগলে মোট দেরির বড় অংশই হয়ে যায় software. তাই আধুনিক সিস্টেম মিশ্র পথ নেয় (খুঁটিনাটি kernel সংস্করণ আর ডিভাইসভেদে আলাদা):

• NAPI (Linux নেটওয়ার্ক): প্রথম প্যাকেটে interrupt, তারপর interrupt বন্ধ রেখে polling; queue খালি হলে আবার interrupt চালু। অংশ ৩-এর stepper-এ পুরোটা দেখবেন।
• io_uring-এর polling: IORING_SETUP_SQPOLL-এ একটি kernel thread অনুরোধের ring poll করে, তাই অ্যাপের system call-ই লাগে না; IORING_SETUP_IOPOLL-এ completion-এর জন্য interrupt-এর বদলে NVMe-র queue poll করা হয় (সাধারণত O_DIRECT ফাইলে).
• Poll-mode driver: DPDK (নেটওয়ার্ক) আর SPDK (স্টোরেজ) পুরো driver user space-এ চালায় আর কয়েকটি core শুধু poll-এর জন্য রেখে দেয় — সর্বোচ্চ গতি, কিন্তু সেই core সারাক্ষণ ১০০% আর বিদ্যুৎ-খরচ বেশি।

৩ · Interrupt-চালিত I/O — controller, MSI-X, top half আর bottom half

পর্ব ০৪-এর stepper-এ আপনি দেখেছেন, একটি interrupt এলে CPU state রেখে IDT থেকে ISR-এর ঠিকানা নেয় আর iret দিয়ে ফেরে। এবার প্রশ্ন: শত শত ডিভাইসের সংকেত CPU-র কাছে পৌঁছায় কীভাবে, কে আগে যাবে, আর কোনটি আটকে রাখা যায়? এই কাজ interrupt controller-এর।

লাইন থেকে বার্তা — MSI আর MSI-X

পুরোনো পদ্ধতিতে interrupt মানে একটি তারে ভোল্টেজ — IRQ লাইন। লাইন কম, তাই কয়েকটি ডিভাইস একটি লাইন ভাগ করত, আর handler-কে প্রতিটি ডিভাইস জিজ্ঞেস করে দেখতে হতো “এটি কি আপনার?” PCI 2.2 আনে MSI (Message Signaled Interrupts): ডিভাইস কোনো তার নাড়ে না, বরং একটি বিশেষ ঠিকানায় একটি ছোট মেমরি-লেখা পাঠায়; সেই লেখার ডেটাই বলে দেয় কোন vector আর কোন core. MSI-তে একটি ডিভাইস সর্বোচ্চ ৩২টি vector পায়; PCI 3.0-এর MSI-X-এ ২০৪৮টি পর্যন্ত, প্রতিটি আলাদা core-এ আলাদা ঠিকানায়।

এর বাস্তব লাভ বিশাল। একটি NVMe SSD প্রতিটি CPU core-এর জন্য আলাদা অনুরোধ-queue রাখতে পারে, আর প্রতিটি queue-এর completion interrupt সেই core-এই আসে — core-গুলোর মধ্যে lock বা cache-এর টানাটানি নেই। নেটওয়ার্ক কার্ডও একইভাবে প্যাকেট কয়েকটি queue-তে ভাগ করে (receive-side scaling).

Vector, priority আর masking

x86-এ ২৫৬টি vector আছে: ০–৩১ CPU-র নিজের exception-এর জন্য সংরক্ষিত (যেমন ১৪ = page fault), ৩২–২৫৫ বাইরের interrupt আর OS-এর নিজের ব্যবহারের জন্য (যেমন core-দের মধ্যে বার্তা)। Local APIC vector-এর উপরের চার বিটকে priority-র শ্রেণি হিসেবে ধরে; একটি উঁচু শ্রেণির interrupt নিচু শ্রেণির handler-কে থামাতে পারে।

• Masking: kernel একটি নির্দিষ্ট লাইন বা ডিভাইসের interrupt বন্ধ রাখতে পারে (controller-এ mask), অথবা এই core-এ সব interrupt সাময়িক বন্ধ করতে পারে (x86-এ cli/sti, Linux-এ local_irq_save()). Critical section-এ handler-এর সাথে ডেটা ভাগ হলে এটি দরকার (পর্ব ২৩)। কিন্তু যত বেশি সময় বন্ধ, তত বেশি interrupt latency.
• NMI (non-maskable interrupt): vector ২, যা সাধারণ masking-এ বন্ধ হয় না — হার্ডওয়্যারের গুরুতর ত্রুটি, watchdog বা profiler-এর জন্য।
• Windows-এর IRQL: Windows NT মাস্কিংকে একটি সংখ্যায় প্রকাশ করে — IRQL. Core যে স্তরে চলছে, তার সমান বা নিচের interrupt অপেক্ষা করে: সাধারণ thread PASSIVE_LEVEL-এ (০), DPC DISPATCH_LEVEL-এ (২), ISR আরও উঁচুতে।

Top half আর bottom half — interrupt-কে দুই ভাগে

ISR চলার সময় অন্তত সেই লাইনের (প্রায়ই পুরো core-এর) নতুন interrupt অপেক্ষায় থাকে, আর ISR ঘুমাতে (sleep) পারে না — কোন process-এর হয়ে ঘুমাবে? তাই নিয়ম: interrupt-এর মুহূর্তে শুধু জরুরি কাজ, বাকিটা পরে নিরাপদ জায়গায়।

• Top half (hard IRQ handler): ডিভাইসকে জানানো “পেয়েছি” (acknowledge), দরকার হলে ডিভাইসের interrupt mask করা, ছোট একটি তথ্য তুলে রাখা, আর bottom half-কে সূচিত করা। Linux-এ request_irq() দিয়ে নিবন্ধিত ফাংশন; ফেরত দেয় IRQ_HANDLED বা ভাগের লাইনে “আমার নয়” বোঝাতে IRQ_NONE.
• Softirq: kernel-এ স্থির কয়েকটি ধরন (নেটওয়ার্ক পাঠানো/গ্রহণ, block, timer, RCU ইত্যাদি)। Hard IRQ শেষে, interrupt আবার চালু রেখে চলে; একই ধরন একসাথে কয়েকটি core-এ চলতে পারে, তাই কোড per-CPU ডেটা আর lock-এ সতর্ক। এখনো ঘুমানো চলে না। বেশি জমলে প্রতি core-এর ksoftirqd thread-এ যায়।
• Tasklet: softirq-এর ওপর বানানো সহজ রূপ, একসাথে একটি core-এই চলে। পুরোনো driver-এ বহুল ব্যবহৃত; সাম্প্রতিক kernel-এ এর বিকল্প হিসেবে BH workqueue এসেছে।
• Workqueue আর threaded IRQ: কাজ চলে একটি সাধারণ kernel thread-এ — process context, তাই ঘুমানো, mutex নেওয়া, ধীর I/O করা সব চলে। request_threaded_irq()-এ top half শুধু thread জাগায়, পুরো handler thread-এ চলে। PREEMPT_RT kernel প্রায় সব interrupt এভাবে চালায়, যাতে real-time কাজকে আগে রাখা যায় (পর্ব ২০)।
• Windows-এ DPC: ISR একটি Deferred Procedure Call queue করে, যা পরে DISPATCH_LEVEL-এ চলে; ঘুমানোর দরকার হলে work item, যা PASSIVE_LEVEL-এর thread-এ চলে। নাম আলাদা, নকশা একই।

একটি নেটওয়ার্ক কার্ডের driver-এ দুই ভাগ কেমন দেখায় (ডিভাইস-নির্দিষ্ট ফাংশনগুলো কাল্পনিক, kernel-এর API আসল):

static irqreturn_t mynic_irq(int irq, void *dev_id)          /* top half */
{
    struct mynic *nic = dev_id;
    u32 st = readl(nic->regs + INT_STATUS);                   /* MMIO read */
    if (!(st & RX_PENDING))
        return IRQ_NONE;                                      /* shared line: not ours */
    writel(st, nic->regs + INT_ACK);                          /* acknowledge */
    mynic_mask_rx_irq(nic);                                   /* no more IRQs for now */
    napi_schedule(&nic->napi);                                /* raise NET_RX softirq */
    return IRQ_HANDLED;
}

static int mynic_poll(struct napi_struct *napi, int budget)   /* bottom half */
{
    struct mynic *nic = container_of(napi, struct mynic, napi);
    int done = mynic_clean_rx_ring(nic, budget);              /* at most budget packets */
    if (done < budget && napi_complete_done(napi, done))
        mynic_unmask_rx_irq(nic);                             /* ring empty: IRQs back on */
    return done;
}
/* probe(): request_irq(irq, mynic_irq, IRQF_SHARED, "mynic", nic);
            netif_napi_add(netdev, &nic->napi, mynic_poll); */

নিচের stepper-এ একটি CPU core-এ একটি প্যাকেটের ঢেউ এই কোডের ভেতর দিয়ে যাচ্ছে:

Interrupt storm আর receive livelock

ধরুন NAPI নেই, আর প্রতিটি প্যাকেটে একটি interrupt. চাপ বাড়লে CPU-র সব সময় যায় top half-এ — প্যাকেট ring থেকে তুলে queue-তে রাখতে। কিন্তু সেই queue থেকে প্যাকেট নিয়ে অ্যাপ পর্যন্ত পৌঁছানোর কাজ (নিচু priority) কখনো সময় পায় না; queue ভরে প্যাকেট ফেলে দেওয়া হয়। CPU ১০০% ব্যস্ত, অথচ কাজের ফল শূন্য — একে বলে receive livelock (সাধারণ livelock-এর একটি রূপ)। ১৯৯৬-৯৭ সালে Jeffrey Mogul আর K. K. Ramakrishnan-এর বিখ্যাত গবেষণাপত্র এটি মেপে দেখায়, আর সমাধান প্রস্তাব করে: চাপ বাড়লে interrupt বন্ধ করে polling, আর প্রতি দফায় কাজের সীমা — NAPI ঠিক এই ধারণার বাস্তব রূপ।

আরেক বিপদ interrupt storm: একটি ত্রুটিপূর্ণ ডিভাইস বা ack না পাওয়া level-triggered লাইন অবিরাম interrupt দেয়। Linux এটি ধরে: কোনো handler বারবার IRQ_HANDLED না বললে log-এ “nobody cared” লিখে লাইনটি বন্ধ করে। প্রতিরোধের আরেকটি হাতিয়ার interrupt coalescing: ডিভাইস কয়েকটি ঘটনা জমিয়ে, অথবা কয়েক মাইক্রোসেকেন্ড অপেক্ষা করে, একটি interrupt দেয়। Linux-এ ethtool -C eth0 rx-usecs 50 ধরনের কমান্ডে এটি বদলানো যায় — throughput বাড়ে, প্রতিটি প্যাকেটের দেরি সামান্য বাড়ে।

৪ · DMA গভীরে — descriptor, scatter-gather, IOMMU আর cache

পর্ব ০৪-এর stepper-এ DMA-র মূল ছবি দেখেছেন: CPU কয়েকটি register-এ উৎস, গন্তব্য আর আকার লিখে দেয়, DMA engine কপি করে, শেষে একটি interrupt. আধুনিক ডিভাইস এক ধাপ এগিয়ে — তারা একটির বদলে শত শত অনুরোধ একসাথে নেয়, RAM-এ রাখা একটি তালিকা থেকে।

Descriptor ring — RAM-এ রাখা কাজের খাতা

Driver RAM-এ একটি বৃত্তাকার অ্যারে বানায় — descriptor ring. প্রতিটি descriptor একটি ছোট struct: buffer-এর ঠিকানা, আকার, কিছু flag (যেমন “এটি এখন ডিভাইসের”). Driver ring-এর মাথায় descriptor যোগ করে, তারপর ডিভাইসের একটি doorbell register-এ (MMIO) নতুন মাথার নম্বর লেখে। ডিভাইস নিজেই DMA দিয়ে descriptor পড়ে, কাজ করে, আর ফল লেখে আরেকটি ring-এ বা descriptor-এর status-এ:

 RAM-এ RX descriptor ring (৮টি ঘর)
 ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┐
 │ done │ done │ dev  │ dev  │ dev  │ dev  │ free │ free │
 └──────┴──────┴──────┴──────┴──────┴──────┴──────┴──────┘
    ▲ driver এখান থেকে পড়ে         ▲ ডিভাইস এখানে লিখবে
 done = ডিভাইস ভরেছে, driver-এর তোলার অপেক্ষায় · dev = খালি buffer, ডিভাইসের হাতে

NVMe-তে একই ধারণার নাম submission queue আর completion queue — প্রতিটি core-এর নিজের জোড়া। এভাবে এক doorbell লেখায় অনেক অনুরোধ যায়, আর এক interrupt-এ অনেক ফল আসে।

Scatter-gather — ছড়ানো page এক অনুরোধে

একটি ১৬ KiB buffer virtual ঠিকানায় একটানা হলেও physical RAM-এ চারটি আলাদা ৪ KiB frame-এ ছড়ানো থাকতে পারে (পর্ব ৩২)। পুরোনো DMA শুধু একটানা physical এলাকা বুঝত — তখন হয় চারটি আলাদা অনুরোধ, নয়তো একটি একটানা “bounce buffer”-এ কপি। Scatter-gather DMA-তে descriptor-এ থাকে (ঠিকানা, দৈর্ঘ্য) জোড়ার একটি তালিকা; ডিভাইস নিজেই ছড়ানো টুকরো থেকে জড়ো করে (gather) বা টুকরোগুলোতে ছড়িয়ে (scatter) লেখে। NVMe-র PRP list আর SGL, নেটওয়ার্ক কার্ডের একাধিক-টুকরোর প্যাকেট — সবই এর রূপ। User space-এ একই ধারণা readv()/writev().

Cycle stealing বনাম burst

DMA engine আর CPU একই মেমরি-পথ ভাগ করে। Cycle stealing-এ DMA একবারে একটি শব্দ সরিয়ে bus ছেড়ে দেয় — CPU মাঝে মাঝে এক-আধ cycle হারায়। Burst mode-এ পুরো ব্লক একটানা — দ্রুত, কিন্তু সেই সময় CPU-র মেমরি-প্রবেশ আটকে থাকতে পারে। আধুনিক PCIe সিস্টেমে পার্থক্যটি কম, তবে ছোট embedded সিস্টেমে আর পরীক্ষায় এই তুলনা প্রায়ই আসে।

IOMMU — DMA-র জন্য page table

একটি bus-master ডিভাইস CPU-কে না জিজ্ঞেস করে RAM-এ লিখতে পারে। Driver-এর একটি বাগ (ভুল ঠিকানা), ত্রুটিপূর্ণ firmware, বা বাইরের পোর্টে লাগানো ক্ষতিকর ডিভাইস — যেকোনোটি kernel-এর মেমরি নষ্ট করতে পারত। IOMMU (Intel-এ VT-d, AMD-তে AMD-Vi, ARM-এ SMMU) ডিভাইস আর RAM-এর মাঝখানে বসে ঠিক MMU-র মতো কাজ করে: ডিভাইস দেখে একটি “I/O virtual address”, IOMMU-র টেবিল সেটিকে physical ঠিকানায় অনুবাদ করে — আর যে ঠিকানা ওই ডিভাইসের জন্য map করা হয়নি, সেখানে লেখা আটকে দিয়ে ত্রুটি জানায়।

তিনটি সুবিধা: (১) নিরাপত্তা — Thunderbolt বা USB4-এর মতো বাইরের পোর্টে লাগানো ডিভাইস শুধু তার জন্য খোলা buffer-ই ছুঁতে পারে; (২) ভুল ধরা — driver-এর ভুল ঠিকানা চুপচাপ মেমরি নষ্ট না করে ধরা পড়ে; (৩) virtualization — একটি PCIe ডিভাইস সরাসরি একটি VM-কে দেওয়া যায় (পর্ব ৫০), কারণ ডিভাইসটি সেই VM-এর মেমরির বাইরে যেতে পারে না। দাম: প্রতিটি map/unmap-এ টেবিল হালনাগাদ আর IOTLB পরিষ্কারের খরচ।

DMA আর cache coherence

CPU-র cache-এ একটি buffer-এর পুরোনো কপি থাকতে পারে, অথচ ডিভাইস সরাসরি RAM-এ নতুন ডেটা লিখেছে — CPU তখন পুরোনো (stale) ডেটা পড়বে। উল্টো দিকে, CPU-র লেখা cache-এ বসে আছে, RAM-এ পৌঁছায়নি, আর ডিভাইস RAM থেকে পুরোনোটা পড়ছে। x86-এ PCIe DMA সাধারণত cache-coherent: হার্ডওয়্যার cache “snoop” করে মিলিয়ে নেয় (পর্ব ০৪-এর cache coherence-এর আত্মীয়)। কিন্তু অনেক ARM SoC-এ DMA coherent নয়; সেখানে software-কে DMA-র আগে cache “flush” (লেখা RAM-এ পাঠানো) আর পরে “invalidate” (পুরোনো কপি ফেলা) করতে হয়।

Linux driver-কে এই পার্থক্য মনে রাখতে হয় না — সে শুধু DMA API ডাকে, আর API প্রতিটি আর্কিটেকচারে ঠিক কাজটি করে (IOMMU map, cache রক্ষণাবেক্ষণ, দরকারে bounce buffer):

dma_addr_t h = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
if (dma_mapping_error(dev, h))          /* IOMMU full, or address unusable */
    return -ENOMEM;
desc->addr  = cpu_to_le64(h);           /* device sees h, not the CPU address */
desc->len   = cpu_to_le16(len);
desc->flags = DESC_OWNED_BY_DEVICE;
writel(tail, nic->regs + RX_DOORBELL);  /* ring the doorbell */

/* ... later, in the completion path: */
dma_unmap_single(dev, h, len, DMA_FROM_DEVICE);  /* invalidate caches if needed */
process_packet(buf);                    /* only now may the CPU read buf */

দীর্ঘস্থায়ী ভাগের এলাকার জন্য (যেমন descriptor ring নিজেই) আছে dma_alloc_coherent(), যা এমন মেমরি দেয় যেখানে CPU আর ডিভাইস দুজনেই সবসময় একই জিনিস দেখে।

৫ · Application I/O interface — block, character, network আর /dev

অ্যাপ কখনো NVMe-র doorbell বা কিবোর্ডের scancode দেখে না। Kernel-এর I/O subsystem হাজার রকম ডিভাইসকে কয়েকটি সাধারণ শ্রেণিতে সাজায়, প্রতিটির একটি মানক interface — অফিসের ফাইল ক্যাবিনেটে যেমন হাজার কাগজ কয়েকটি ড্রয়ারে, প্রতিটি ড্রয়ার খোলার নিয়ম এক।

Unix-এর দর্শন “সবকিছুই ফাইল”: block আর character device-কে /dev-এর একটি device file দিয়ে খোলা যায়, সাধারণ open/read/write-এ। ফাইলটির ভেতরে কোনো ডেটা থাকে না; থাকে দুটি সংখ্যা — major number (কোন driver) আর minor number (সেই driver-এর কোন ডিভাইস বা অংশ)। আধুনিক Linux-এ এই ফাইলগুলো devtmpfs আর udev ডিভাইস খোঁজার সাথে সাথে বানায়। এবার অনলাইন রানারের container-টিতেই দেখি (কোনো ফাইল পড়া না গেলে script থামে না, শুধু জানায়):

echo "== three character devices =="
ls -l /dev/null /dev/zero /dev/urandom
echo "== type and major:minor via stat (hex) =="
stat -c '%-13n %F  major=%t minor=%T' /dev/null /dev/zero /dev/urandom
echo "== reading them =="
printf 'zero:    '; head -c 8 /dev/zero | od -An -tx1
printf 'urandom: '; head -c 8 /dev/urandom | wc -c
echo "== /proc/interrupts (first lines, cut) =="
if [ -r /proc/interrupts ]; then head -n 6 /proc/interrupts | cut -c1-100
else echo "not readable here"; fi
echo "== /proc/devices (first lines) =="
head -n 12 /proc/devices

== three character devices ==
crw-rw-rw- 1 nobody nogroup 1, 3 Aug  6 17:54 /dev/null
crw-rw-rw- 1 nobody nogroup 1, 9 Aug  6 17:54 /dev/urandom
crw-rw-rw- 1 nobody nogroup 1, 5 Aug  6 17:54 /dev/zero
== type and major:minor via stat (hex) ==
/dev/null     character special file  major=1 minor=3
/dev/zero     character special file  major=1 minor=5
/dev/urandom  character special file  major=1 minor=9
== reading them ==
zero:     00 00 00 00 00 00 00 00
urandom: 8
== /proc/interrupts (first lines, cut) ==
           CPU0       CPU1
  0:        180          0   IO-APIC   2-edge      timer
  1:          9          0   IO-APIC   1-edge      i8042
  8:          0          1   IO-APIC   8-edge      rtc0
  9:          0          0   IO-APIC   9-fasteoi   acpi
 12:          0         15   IO-APIC  12-edge      i8042
== /proc/devices (first lines) ==
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  5 ttyprintk
  7 vcs
 10 misc
 13 input

Windows আর macOS-এ

Windows-এ major/minor নেই। প্রতিটি ডিভাইস একটি device object (যেমন \Device\HarddiskVolume3); অ্যাপ সেটি খোলে CreateFile দিয়ে, বিশেষ আদেশ পাঠায় DeviceIoControl দিয়ে (ioctl-এর সমতুল্য), আর driver প্রতিটি অনুরোধ পায় একটি IRP (I/O Request Packet) হিসেবে। macOS-এ BSD-ধাঁচের /dev আছে, কিন্তু driver-এর কাঠামো Apple-এর IOKit.

I/O protection — অ্যাপ কেন সরাসরি port ছুঁতে পারে না

সব I/O নির্দেশ privileged instruction: x86-এর in/out user mode-এ চালালে exception হয় (যদি না kernel বিশেষভাবে অনুমতি দেয়), আর ডিভাইসের MMIO ঠিকানা কোনো user process-এর page table-এ রাখা হয় না। তাই I/O করার একমাত্র পথ system call, যেখানে kernel অনুমতি (ফাইলের permission, পর্ব ৪৭), ঠিকানার বৈধতা আর সীমা যাচাই করে। Linux-এ ioperm() দিয়ে নির্দিষ্ট port খোলা যায়, কিন্তু তাতে CAP_SYS_RAWIO ক্ষমতা লাগে — সাধারণ ব্যবহারকারী পারেন না।

৬ · Blocking, non-blocking আর asynchronous I/O

ব্যাংকের টোকেন-কাউন্টারের কথা ভাবুন। তিনভাবে অপেক্ষা করা যায়: কাউন্টারের সামনে দাঁড়িয়ে থাকা যতক্ষণ না কাজ হয় (blocking); একবার জিজ্ঞেস করে “এখনো হয়নি” শুনে চলে গিয়ে অন্য কাজ, পরে আবার জিজ্ঞেস (non-blocking); অথবা ফর্ম জমা দিয়ে চলে যাওয়া, কাজ শেষে ব্যাংক SMS পাঠাবে (asynchronous).

• Blocking: read() ডেটা না আসা পর্যন্ত process-কে wait queue-তে ঘুম পাড়িয়ে রাখে (পর্ব ০৮-এর blocked অবস্থা)। লেখা সহজ, কিন্তু একটি thread একসাথে একটিই অপেক্ষা করতে পারে।
• Non-blocking: O_NONBLOCK দেওয়া fd-তে ডেটা না থাকলে read() সাথে সাথে −১ ফেরায় আর errno হয় EAGAIN (একই মান EWOULDBLOCK). কিন্তু এর ওপর লুপ ঘোরালে আবার busy waiting!
• I/O multiplexing: সমাধান — kernel-কে বলা “এই fd-গুলোর যেকোনোটি প্রস্তুত হলে জাগাবেন”. select (4.2BSD, ১৯৮৩) আর poll প্রতিবার পুরো তালিকা kernel-এ দেয়, kernel প্রতিটি দেখে — fd হাজার হলে খরচ O(n). Linux-এর epoll (২.৫/২.৬, ২০০২-এর আশেপাশে) আর BSD/macOS-এর kqueue (FreeBSD, ২০০০) তালিকাটি kernel-এ একবার নিবন্ধন করে, আর শুধু প্রস্তুতগুলো ফেরত দেয়। nginx, Node.js-এর libuv, Redis — সবাই এর ওপর দাঁড়িয়ে।
• Asynchronous I/O: অ্যাপ অনুরোধ জমা দিয়ে চলে যায়; kernel কাজটি শেষ করে জানায়। “প্রস্তুত হলে জানাও” (readiness, epoll) আর “শেষ হলে জানাও” (completion) — এই পার্থক্যই মূল। Windows-এর IOCP (I/O completion port) completion মডেলের পুরোনো উদাহরণ; Linux-এ আধুনিক উত্তর io_uring (৫.১, ২০১৯)। POSIX-এর aio_read()-ও আছে, তবে glibc এটি ভেতরে thread দিয়ে চালায়।

এবার প্রথম তিনটি আচরণ আসল kernel-এ দেখি — একটি pipe-এ: খালি pipe-এ non-blocking read, ৩০০ ms timeout-এর poll, একটি child ২০০ ms পরে লিখলে blocking read কতক্ষণ ঘুমায়, আর ডেটা আগেই থাকলে poll কী করে। সময় ঠিক সংখ্যায় না ছেপে সম্পর্ক ছাপা হয়েছে, যাতে প্রতি রানে একই আউটপুট আসে:

#define _GNU_SOURCE
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <time.h>
#include <unistd.h>
#include <sys/wait.h>
static struct timespec t0;
static void mark(void) { clock_gettime(CLOCK_MONOTONIC, &t0); }
static long ms(void) {
    struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t);
    return (t.tv_sec - t0.tv_sec) * 1000 + (t.tv_nsec - t0.tv_nsec) / 1000000;
}
int main(void) {
    int fd[2]; char buf[32]; if (pipe(fd) != 0) return 1;
    int fl = fcntl(fd[0], F_GETFL);
    fcntl(fd[0], F_SETFL, fl | O_NONBLOCK);                       /* 1: non-blocking */
    ssize_t n = read(fd[0], buf, sizeof buf);
    printf("1) non-blocking read, empty pipe: n=%zd errno=%s\n", n, errno == EAGAIN ? "EAGAIN" : "other");
    struct pollfd p = { .fd = fd[0], .events = POLLIN };
    mark(); int r = poll(&p, 1, 300);                              /* 2: timeout 300 ms */
    printf("2) poll, nothing written: returned %d, waited >= 290 ms: %s\n", r, ms() >= 290 ? "yes" : "no");
    fflush(stdout);                                               /* before fork! */
    if (fork() == 0) { usleep(200000); _exit(write(fd[1], "hello", 5) == 5 ? 0 : 1); }
    fcntl(fd[0], F_SETFL, fl);                                    /* 3: blocking again */
    mark(); n = read(fd[0], buf, sizeof buf);
    printf("3) blocking read: n=%zd \"%.5s\", slept >= 190 ms: %s\n", n, buf, ms() >= 190 ? "yes" : "no");
    wait(NULL);
    if (write(fd[1], "x", 1) != 1) return 1;                      /* 4: data already there */
    mark(); r = poll(&p, 1, 300);
    printf("4) poll, data ready: returned %d, POLLIN=%s, waited < 50 ms: %s\n",
           r, (p.revents & POLLIN) ? "yes" : "no", ms() < 50 ? "yes" : "no");
    return 0;
}

1) non-blocking read, empty pipe: n=-1 errno=EAGAIN
2) poll, nothing written: returned 0, waited >= 290 ms: yes
3) blocking read: n=5 "hello", slept >= 190 ms: yes
4) poll, data ready: returned 1, POLLIN=yes, waited < 50 ms: yes

৭ · Buffering, caching, spooling — আর buffering-এর হিসাব

Kernel I/O-র পথে ডেটা সাময়িক রাখে তিনটি কারণে: (১) গতির অমিল — নেটওয়ার্ক থেকে ধীরে আসা ফাইল জমিয়ে একবারে ডিস্কে লেখা; (২) আকারের অমিল — নেটওয়ার্কের ছোট প্যাকেট জুড়ে বড় বার্তা, বা অ্যাপের ১০০ বাইটের লেখা ৪ KiB ব্লকে মেলানো; (৩) copy semantics — write() ফেরার পর অ্যাপ buffer বদলালেও যা লেখার কথা ছিল সেটিই যাবে, কারণ kernel আগেই নিজের কাছে কপি রেখেছে।

Single, double আর circular buffer

একটি প্রোগ্রাম ডিস্ক থেকে n টি ব্লক পড়ে, প্রতিটিতে কিছু হিসাব করে। তিনটি সময় ধরা যাক: T = একটি ব্লক ডিভাইস থেকে buffer-এ আসার সময়, C = একটি ব্লকে হিসাবের সময়, M = system buffer থেকে process-এর মেমরিতে কপির সময়।

• Buffer ছাড়া: ডিভাইস সরাসরি process-এর মেমরিতে লেখে; পড়া আর হিসাব পালাক্রমে, কোনো overlap নেই। প্রতি ব্লকে T + C.
• Single buffer: kernel-এর একটি buffer. ডিভাইস buffer ভরে, kernel সেটি process-এ কপি করে (M), তারপর process হিসাব করার সময়েই ডিভাইস পরের ব্লক দিয়ে buffer আবার ভরে। স্থিত অবস্থায় প্রতি ব্লকে max(C, T) + M.
• Double buffer: দুটি buffer. Process একটিতে কাজ করে, ডিভাইস তখন অন্যটি ভরে, তারপর দুজন জায়গা বদল করে। প্রতি ব্লকে max(C, T) — ধীরতর পক্ষটিই গতি ঠিক করে।
• Circular buffer: দুইয়ের বেশি buffer একটি বৃত্তে (অংশ ৪-এর descriptor ring-এর মতো)। গড় গতি double-এর মতোই, কিন্তু হঠাৎ ঢেউ (burst) সামলাতে পারে — যেমন নেটওয়ার্কের প্যাকেট বা ভিডিওর ফ্রেম।

শুরু আর শেষের হিসাবসহ মোট সময়: buffer ছাড়া n(T + C); single = T + M + C + (n − 1)(max(C, T) + M); double = T + C + (n − 1)·max(C, T). একটি পরীক্ষা-ধাঁচের হিসাব: n = ১০, T = ৫ ms, C = ৩ ms, M = ১ ms. Buffer ছাড়া ১০ × ৮ = ৮০ ms. Single: ৫ + ১ + ৩ + ৯ × (৫ + ১) = ৯ + ৫৪ = ৬৩ ms. Double: ৫ + ৩ + ৯ × ৫ = ৫৩ ms. Throughput-এর ভাষায়, স্থিত অবস্থায় প্রতি ব্লক ৮, ৬ আর ৫ ms — সেকেন্ডে ১২৫, প্রায় ১৬৭ আর ২০০টি ব্লক। নিচের simulator ধাপে ধাপে ঘটনা মিলিয়ে এই সংখ্যা বের করে, আর আরও দুটি ক্ষেত্র দেখায়:

// Total time to read and process n blocks: T = transfer, C = compute, M = move (buffer -> user)
function simulate(n, T, C, M) {
  const none = n * (T + C);                    // read and compute strictly alternate
  let full = T, done = 0;                      // single: one kernel buffer
  for (let k = 1; k <= n; k++) {
    const moved = Math.max(full, done) + M;    // copy out when buffer full AND process free
    done = moved + C;                          // process computes block k
    full = moved + T;                          // device refills the freed buffer meanwhile
  }
  const single = done;
  const fillEnd = [], compEnd = [];            // double: blocks alternate between 2 buffers
  for (let k = 0; k < n; k++) {
    const devFree = k > 0 ? fillEnd[k - 1] : 0;
    const bufFree = k > 1 ? compEnd[k - 2] : 0; // buffer k%2 is free once block k-2 is done
    fillEnd[k] = Math.max(devFree, bufFree) + T;
    compEnd[k] = Math.max(fillEnd[k], k > 0 ? compEnd[k - 1] : 0) + C;
  }
  return [none, single, compEnd[n - 1]];
}
const cases = [[10, 5, 3, 1], [10, 2, 4, 1], [10, 5, 5, 0]];
console.log("case (ms)            none  single  double");
for (const [n, T, C, M] of cases) {
  const [a, b, c] = simulate(n, T, C, M);
  const tag = `n=${n} T=${T} C=${C} M=${M}`;
  console.log(tag.padEnd(20) + String(a).padStart(5) + String(b).padStart(8) + String(c).padStart(8));
}
console.log("steady state per block: none T+C, single max(C,T)+M, double max(C,T)");

case (ms)            none  single  double
n=10 T=5 C=3 M=1       80      63      53
n=10 T=2 C=4 M=1       60      52      42
n=10 T=5 C=5 M=0      100      55      55
steady state per block: none T+C, single max(C,T)+M, double max(C,T)

I/O scheduling আর error handling — সংক্ষেপে

I/O scheduling মানে জমে থাকা অনুরোধগুলোর ক্রম ঠিক করা — পাশাপাশি ব্লকের অনুরোধ জুড়ে দেওয়া (merge), HDD-তে মাথার নড়াচড়া কমানো, আর কোনো process যেন অনন্তকাল অপেক্ষা না করে। Linux-এর block layer এখন blk-mq (multi-queue) ভিত্তিক, আর scheduler হিসেবে mq-deadline, bfq, kyber বা none (দ্রুত NVMe-তে প্রায়ই) বেছে নেওয়া যায়। FCFS, SSTF, SCAN, C-SCAN-এর হিসাবসহ পুরো আলোচনা পর্ব ৪০-এ।

Error handling: ডিভাইস ব্যর্থ হতে পারে সাময়িকভাবে (নেটওয়ার্কে প্যাকেট হারানো, ডিস্কের একটি পড়া ব্যর্থ) বা স্থায়ীভাবে (ডিস্কের নষ্ট sector, controller মরে যাওয়া)। Kernel সাধারণত কয়েকবার আবার চেষ্টা করে, না হলে system call-কে −১ আর errno = EIO ফেরত দেয়, আর বিস্তারিত লেখে kernel log-এ (dmesg, Windows-এ Event Viewer). ডিস্ক নিজেও নিজের স্বাস্থ্যের খাতা রাখে — SMART বা NVMe-র health log, যা smartctl দিয়ে পড়া যায়।

৮ · Device driver — kernel আর হার্ডওয়্যারের দোভাষী

Driver-এর দুটি মুখ: ওপরের দিকে kernel-এর মানক interface (যেমন Linux-এর file_operations বা block device-এর queue), নিচের দিকে একটি নির্দিষ্ট controller-এর register, ring আর interrupt-এর ভাষা। এই স্তর-ভাগের কারণেই একই cat কমান্ড SATA ডিস্ক, NVMe আর USB pen drive — সবখানে চলে। একটি ফাইল পড়ার স্তরগুলো:

একটি character driver-এর কঙ্কাল

নিচের Linux module একটি /dev/hello বানায়, যা পড়লে একটি লাইন দেয়। এখানে misc device কাঠামো ব্যবহার করা হয়েছে (major ১০, minor kernel ঠিক করে) — সবচেয়ে ছোট বৈধ উদাহরণ। এটি এই পাতায় চলবে না: kernel module লোড করতে root আর kernel-এর header লাগে।

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>

static const char msg[] = "hello from the kernel\n";

static ssize_t hello_read(struct file *f, char __user *ubuf,
                          size_t len, loff_t *ppos)
{
    size_t left;
    if (*ppos >= sizeof(msg) - 1)
        return 0;                                  /* EOF */
    left = sizeof(msg) - 1 - *ppos;
    if (len > left)
        len = left;
    if (copy_to_user(ubuf, msg + *ppos, len))      /* never memcpy to a user pointer */
        return -EFAULT;
    *ppos += len;
    return len;
}

static const struct file_operations hello_fops = {
    .owner = THIS_MODULE,
    .read  = hello_read,          /* .open, .release, .write, .unlocked_ioctl ... optional */
};

static struct miscdevice hello_dev = {
    .minor = MISC_DYNAMIC_MINOR,
    .name  = "hello",             /* devtmpfs/udev creates /dev/hello */
    .fops  = &hello_fops,
};
module_misc_device(hello_dev);    /* misc_register() on load, deregister on unload */
MODULE_LICENSE("GPL");

লক্ষ করুন: (১) driver কোনো ফাইলের নাম বা path জানে না — VFS fd থেকে struct file খুঁজে f_op->read ডাকে; (২) copy_to_user ঠিকানাটি user-এর অংশে কি না যাচাই করে, আর page fault হলেও নিরাপদে -EFAULT দেয় — kernel-এর সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা-নিয়মগুলোর একটি; (৩) *ppos বাড়িয়ে driver জানায় পরের পড়া কোথা থেকে, আর ০ ফেরত মানে EOF. Build আর পরীক্ষা নিজের যন্ত্রে এমন দেখায়:

$ make -C /lib/modules/$(uname -r)/build M=$PWD modules
$ sudo insmod hello_misc.ko
$ ls -l /dev/hello
crw------- 1 root root 10, 123 Oct 26 10:15 /dev/hello
$ sudo cat /dev/hello
hello from the kernel
$ sudo rmmod hello_misc

User space-এর driver

সব driver kernel-এ থাকতে হবে, এমন নয়। Linux-এর UIO একটি ডিভাইসের register এলাকা user process-এ mmap করতে দেয়, আর interrupt আসে একটি fd-এর read হিসেবে; VFIO এর সাথে IOMMU যোগ করে, যাতে user-space driver (DPDK, SPDK) বা একটি VM ডিভাইসের পূর্ণ নিয়ন্ত্রণ পায় কিন্তু নিজের মেমরির বাইরে DMA করতে পারে না। File system-ও user space-এ লেখা যায় — FUSE (যেমন sshfs; পর্ব ৪২)। Windows-এ একই ধারণা UMDF (user-mode) বনাম KMDF (kernel-mode) driver; macOS ১০.১৫ থেকে Apple DriverKit দিয়ে অনেক driver user space-এ সরাচ্ছে।

Driver — নির্ভরযোগ্যতার সবচেয়ে বড় ঝুঁকি

Linux-এর সোর্স কোডের অর্ধেকের বেশি drivers/ ফোল্ডারে। কোডগুলো লেখেন হাজারো নির্মাতা, প্রায়ই এমন হার্ডওয়্যারের জন্য যা মূল ডেভেলপারদের হাতে নেই, আর চলে সর্বোচ্চ অধিকারে — একটি ভুল pointer পুরো kernel ফেলে দেয়। প্রতিরক্ষার পথ: স্থির-বিশ্লেষণ টুল, চলার সময় যাচাই (Windows-এর Driver Verifier, Linux-এর KASAN), driver signing, user-space driver আর নিরাপদ ভাষা (Linux ৬.১ থেকে Rust-এর প্রাথমিক সমর্থন) — ইতিহাস ভাবনার প্রশ্ন ২-এ।

৯ · একটি read()-এর জীবনচক্র, আর পারফরম্যান্সের কৌশল

এবার সব টুকরো এক জায়গায়। একটি process একটি ফাইলের প্রথম ৪ KiB পড়ছে, ফাইলটি NVMe SSD-তে, আর page cache-এ নেই (cache miss). প্রতিটি ধাপে কোন স্তর কাজ করছে, process কোন অবস্থায়, আর ডেটা কোথায় — দেখুন:

খরচ কমানোর তিন দিক

উপরের পথে খরচ আসে তিন জায়গা থেকে, আর আধুনিক কৌশলগুলো এক-একটিকে লক্ষ্য করে:

• Context switch আর mode switch কমানো: একবারে বড় ব্লক পড়া, readv/writev, epoll-এ এক ঘুমে অনেক ঘটনা, io_uring-এ এক system call-এ অনেক অনুরোধ (বা SQPOLL-এ কোনো system call-ই নয়)।
• কপি কমানো — zero-copy: একটি ওয়েব সার্ভার ফাইল পাঠাতে সাধারণত read() (page cache → user) আর write() (user → socket buffer) করে — দুটি CPU-কপি, দুটি system call. sendfile() (Linux ২.২ থেকে) kernel-কে বলে সরাসরি page cache থেকে socket-এ পাঠাতে; NIC scatter-gather DMA পারলে ডেটা CPU দিয়ে একবারও কপি হয় না।
• Interrupt কমানো: coalescing (অংশ ৩), NAPI, আর খুব দ্রুত ডিভাইসে polling (অংশ ২)।

১০ · AI-এর যুগে I/O-র কোড আর পরামর্শ — যাচাই

“epoll দিয়ে একটি TCP সার্ভার লিখে দাও” — AI কয়েক সেকেন্ডে কোড দেবে, আর তা প্রথম পরীক্ষায় প্রায়ই চলেও। সমস্যা দেখা দেয় চাপের মধ্যে, অন্য kernel-এ, বা নিরাপত্তায়। I/O-র ক্ষেত্রে AI-এর সাধারণ ভুল:

AI-এর দেওয়া I/O কোড বা কমান্ড ব্যবহারের আগে — চেকলিস্ট

• কোডটি আমার OS, kernel সংস্করণ আর distro-র জন্য — man page (man 2 epoll_ctl, man 2 read) আর kernel docs-এর সাথে মিলিয়েছি
• প্রতিটি read/write/poll-এর ফেরত মান, EAGAIN, EINTR আর আংশিক কপির পথ পরীক্ষা করেছি
• নিষ্ক্রিয় অবস্থায় প্রোগ্রাম CPU খাচ্ছে না (top-এ ~০%) — busy loop নেই
• ছোট পরীক্ষা নয়, চাপের মধ্যে (অনেক client, বড় ডেটা, ধীর client) চালিয়ে দেখেছি
• ডিভাইসের অনুমতির জন্য chmod 777 বা sudo নয়, সঠিক group বা udev rule ব্যবহার করেছি; IOMMU-র মতো সুরক্ষা বন্ধ করিনি
• কোনো সংখ্যার দাবি (latency, throughput, buffering-এর সময়) হাতে বা নিজের মাপে মিলিয়েছি