মোবাইল, embedded আর real-time OS — Android, iOS আর RTOS

১ · ছোট যন্ত্রের বড় সীমাবদ্ধতা — যা OS-এর নকশা বদলে দেয়

এতদিন কোর্সে আমরা মূলত ডেস্কটপ আর সার্ভারের চোখে OS দেখেছি: বিদ্যুৎ দেয়ালের প্লাগ থেকে আসে, RAM কম পড়লে ডিস্কে swap আছে, গরম হলে পাখা ঘোরে। পর্ব ২-এ দেখেছেন মোবাইল OS আর embedded system কীভাবে এল। এবার প্রশ্ন: এদের ভেতরটা আলাদা কেন? উত্তর এক কথায় — সীমাবদ্ধতা. পকেটের ফোন বা দেয়ালের বিদ্যুৎ-মিটারের OS প্রতিটি সিদ্ধান্তে এই প্রশ্নগুলো করে:

বাংলাদেশে বহু মানুষের কাছে ইন্টারনেট মানেই স্মার্টফোন — অনেকের প্রথম কম্পিউটারই একটি কম দামের Android ফোন। কম RAM-এ অ্যাপ বারবার রিস্টার্ট হওয়া, লোডশেডিংয়ের দিনে ব্যাটারি বাঁচানো, দুর্বল নেটওয়ার্কে অ্যাপের আচরণ — এগুলো এখানকার ডেভেলপারদের রোজকার প্রশ্ন, আর এই পর্ব তাদের পেছনের কারণ বোঝায়।

২ · Android-এর স্তর — Linux kernel থেকে অ্যাপ framework

Android-এর নিচে Linux kernel, কিন্তু এটি Ubuntu-র মতো একটি “Linux distro” নয়। GNU-র glibc-এর বদলে Android নিজের ছোট C লাইব্রেরি Bionic ব্যবহার করে, X11 বা Wayland নেই, shell-এর টুলও আলাদা। ওপরের স্তরগুলো Google-এর নিজস্ব। Android-এর অফিসিয়াল ডকুমেন্টেশন সাধারণত স্তরগুলো এভাবে দেখায় (সরলীকৃত; সংস্করণভেদে নাম বদলায়):

Kernel-এর Android-বিশেষ অংশ

• Binder: Android-এর প্রধান IPC. অ্যাপের “লোকেশন চাই” অনুরোধ Binder দিয়ে system_server-এ যায়, আর kernel সাথে জুড়ে দেয় পাঠানো প্রসেসের UID ও PID — অনুমতি যাচাইয়ের জন্য। খুঁটিনাটি পর্ব ১২-এ।
• ashmem থেকে memfd: প্রসেসের মধ্যে মেমরি ভাগের জন্য Android-এর নিজস্ব driver, যা চাপের সময় kernel-কে কিছু অংশ ফেলে দিতে দিত। এর জায়গা ধীরে ধীরে নিচ্ছে মূল Linux-এর memfd_create() — একটি নামহীন, RAM-ভিত্তিক ফাইল, যার file descriptor অন্য প্রসেসে পাঠানো যায় (সংস্করণভেদে আলাদা)।
• Wake lock-এর ইতিহাস: ফোন যত দ্রুত সম্ভব গভীর ঘুমে (suspend) যেতে চায়, কিন্তু গান বাজার সময় বা ডাউনলোডের মাঝে যাওয়া চলবে না। Android-এর প্রথম দিকের kernel-এ “wakelock” নামের একটি ব্যবস্থা ছিল: কেউ lock ধরে থাকলে suspend হবে না। মূল Linux প্রথমে এই নকশা নেয়নি; পরে একই প্রয়োজনে মূল kernel-এ “wakeup source” আর autosleep আসে (মোটামুটি ২০১২ সালের দিকে)। অ্যাপের স্তরে নামটি এখনো PowerManager.WakeLock.
• Low memory killer → lmkd: শুরুতে এটি kernel-এর একটি driver ছিল, যা ফাঁকা RAM নির্দিষ্ট সীমার নিচে নামলে পেছনের অ্যাপ মারত। পরে কাজটি user space-এর একটি daemon, lmkd-তে সরানো হয়, আর নতুন সংস্করণে lmkd kernel-এর PSI (পর্ব ৩৮) দেখে সিদ্ধান্ত নেয় — “কাজগুলো মেমরির জন্য কতক্ষণ আটকে আছে”। অংশ ৪-এ ধাপে ধাপে দেখবেন।

HAL, native লাইব্রেরি, ART আর framework

HAL (hardware abstraction layer): প্রতিটি নির্মাতার ক্যামেরা বা অডিও চিপ আলাদা; HAL একটি নির্দিষ্ট interface দেয়, নির্মাতা নিজের চিপের জন্য তা বাস্তবায়ন করেন, আর framework শুধু interface চেনে।

Native লাইব্রেরি C/C++-এ লেখা — Bionic, OpenGL ES/Vulkan, SQLite, মিডিয়া codec. ART (Android Runtime): Android অ্যাপ সাধারণত Kotlin বা Java-তে লেখা, যা DEX নামের bytecode-এ পরিণত হয়। একে চালানোর যন্ত্র প্রথমে ছিল Dalvik — একটি interpreter, Android 2.2 থেকে তাতে JIT (চলার সময় ঘন ঘন চলা কোড machine code-এ রূপান্তর) যুক্ত হয়। Android 4.4-এ পরীক্ষামূলকভাবে আর 5.0 থেকে ডিফল্ট হিসেবে আসে ART, যা শুরুতে ইনস্টলের সময়েই পুরো অ্যাপ machine code-এ রূপান্তর করত — AOT (ahead-of-time). এতে অ্যাপ দ্রুত চলল, কিন্তু ইনস্টল আর সিস্টেম-আপডেট ধীর হলো, storage-ও বেশি লাগল। তাই Android 7.0 থেকে মিশ্র পথ: প্রথমে JIT, চলার সময় কোন কোড বেশি চলে তার profile রাখা, আর ফোন চার্জে ও অলস থাকলে সেই অংশ AOT-তে রূপান্তর। (সংস্করণগুলো সাধারণভাবে উদ্ধৃত।) ART-এর garbage collector-ও এমনভাবে বানানো, যাতে পর্দা আঁকার মাঝে লম্বা বিরতি না আসে।

Application framework: অ্যাপ-ডেভেলপার যে Java/Kotlin API দেখেন — Activity, Service, ContentProvider, NotificationManager. এর বেশিরভাগ “সেবা” আসলে চলে একটি বিশাল সিস্টেম-প্রসেস system_server-এ; অ্যাপ Binder দিয়ে তাকে ডাকে। অর্থাৎ Android-এর “OS”-এর বড় অংশ kernel-এর বাইরে, user space-এ।

অনুমতি আর মডুলার আপডেট

পর্ব ৪৯-এ দেখেছেন, প্রতিটি অ্যাপ নিজের Linux UID, SELinux আর seccomp-এর sandbox-এ চলে। তার ওপরে আছে অনুমতির মডেল। Android 6.0 (২০১৫) থেকে বিপজ্জনক অনুমতি — ক্যামেরা, মাইক্রোফোন, লোকেশন, কন্টাক্ট — ইনস্টলের সময় একবারে নয়, প্রথম ব্যবহারের মুহূর্তে চাওয়া হয়, আর ব্যবহারকারী পরে settings থেকে ফিরিয়ে নিতে পারেন: runtime permission. পরে “শুধু এবার” ধরনের বিকল্পও এসেছে।

পুরোনো সমস্যা: নতুন Android ফোনে পৌঁছাতে নির্মাতা আর চিপ-কোম্পানির কোড নতুন করে মেলাতে হয়, তাই বহু ফোন আপডেট পেত দেরিতে বা পেতই না। এর জবাবে Android 8.0 (২০১৭)-এ Project Treble: নির্মাতার hardware-নির্ভর অংশ (vendor partition, HAL) আর Android framework-এর মাঝে একটি স্থির interface, যাতে framework আলাদাভাবে হালনাগাদ করা যায়। Kernel-এর ক্ষেত্রেও একই চিন্তায় পরে GKI (Generic Kernel Image): Google-এর রক্ষণাবেক্ষণ করা একটি সাধারণ kernel, আর নির্মাতার driver আলাদা module হিসেবে (Android 12-এর দিকের নতুন ফোনে সাধারণভাবে বাধ্যতামূলক বলে জানা যায়)। লক্ষ্য একটাই — নিরাপত্তা-প্যাচ দ্রুত ফোনে পৌঁছানো।

৩ · Zygote — একবার তৈরি, বারবার fork

একটি Android অ্যাপ চালু করতে runtime শুরু, হাজার হাজার framework class লোড আর resource প্রস্তুত করা লাগে। প্রতিবার এসব করলে চালু ধীর হতো, আর প্রতিটি অ্যাপ একই জিনিসের আলাদা কপি রাখত। Android-এর সমাধান পর্ব ১০-এর fork() আর পর্ব ৩৫-এর copy-on-write-এর সুন্দর প্রয়োগ: বুটের সময় একটি প্রসেস — Zygote (জীববিজ্ঞানে নিষিক্ত কোষ, যা থেকে পুরো জীব জন্মায়) — একবার runtime চালু করে, সাধারণ class আর resource preload করে socket-এ অপেক্ষা করে। নতুন অ্যাপ লাগলে Zygote শুধু fork করে; সন্তান প্রস্তুত runtime পায়, আর সব page বাবার সাথে ভাগ থাকে — যতক্ষণ কেউ সেগুলোতে লেখে না।

এবার Zygote-এর মূল যুক্তি নিজে মেপে দেখুন। নিচের C প্রোগ্রামে বাবা (“zygote”) একবার একটি ৮ MiB-র টেবিল তৈরি করে ভরে রাখে — যেন preload করা class. তারপর একে একে চারটি সন্তান (“app”) fork করে। প্রথম তিনটি টেবিলের প্রতিটি page থেকে শুধু পড়ে; চতুর্থটি প্রতিটি page-এ লেখে। প্রতিটি সন্তান নিজের কাজের আগে-পরে getrusage() দিয়ে নিজের minor page fault গোনে। সন্তানগুলো একটির পর একটি চলে (বাবা প্রতিবার wait করে), তাই ছাপার ক্রম নির্দিষ্ট।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/resource.h>
#include <sys/wait.h>
#define PAGES 2048                     /* 2048 pages x 4 KiB = 8 MiB "preloaded" table */
static long minflt(void) { struct rusage ru; getrusage(RUSAGE_SELF, &ru); return ru.ru_minflt; }
int main(void) {
    long pg = sysconf(_SC_PAGESIZE);
    char *table = mmap(NULL, PAGES * pg, PROT_READ | PROT_WRITE,
                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (table == MAP_FAILED) { perror("mmap"); return 1; }
    madvise(table, PAGES * pg, MADV_NOHUGEPAGE);  /* keep plain 4 KiB pages */
    memset(table, 7, PAGES * pg);                 /* zygote: initialise once */
    printf("zygote: table of %d pages ready (page size %ld)\n", PAGES, pg);
    const char *name[] = { "app-A", "app-B", "app-C", "app-W" };
    for (int i = 0; i < 4; i++) {
        fflush(stdout);                           /* nothing buffered before fork */
        if (fork() == 0) {
            long before = minflt(), sum = 0;
            for (long p = 0; p < PAGES; p++) {
                if (i < 3) sum += table[p * pg];    /* read only: stay shared */
                else table[p * pg] = 1;            /* write: kernel copies page */
            }
            long f = minflt() - before;
            printf("%s: %-5s sum=%-5ld minor faults = %4ld -> %s\n", name[i],
                   i < 3 ? "read" : "write", sum, f, f < 64 ? "pages shared" : "pages copied");
            fflush(stdout); _exit(0);             /* _exit() skips stdio flushing */
        }
        wait(NULL);
    }
    return 0;
}

zygote: table of 2048 pages ready (page size 4096)
app-A: read  sum=14336 minor faults =    0 -> pages shared
app-B: read  sum=14336 minor faults =    0 -> pages shared
app-C: read  sum=14336 minor faults =    0 -> pages shared
app-W: write sum=0     minor faults = 2048 -> pages copied

নিজের Android ফোনে (Developer options-এ USB debugging চালু করে, কম্পিউটার থেকে) এই বংশধারা দেখা যায়। নিচে একটি উদাহরণ — সংখ্যা আর নাম যন্ত্রভেদে আলাদা হবে, আর ৬৪-bit ফোনে Zygote-এর নাম সাধারণত zygote64:

$ adb shell ps -A -o USER,PID,PPID,NAME | grep -E "zygote|com.android.settings"
root           612     1 zygote64
root           613     1 zygote
u0_a98        4721   612 com.android.settings

Settings অ্যাপের PPID = ৬১২, অর্থাৎ বাবা zygote64, আর UID অ্যাপের নিজস্ব u0_a98 — পর্ব ১০-এর fork আপনার পকেটেই।

৪ · অ্যাপের জীবনচক্র, importance আর lmkd — RAM ফুরোলে কে যাবে

ডেস্কটপে প্রোগ্রাম বন্ধ করেন আপনি; মোবাইলে প্রায়ই করে OS. তাই অ্যাপের একটি নির্দিষ্ট জীবনচক্র আছে। একটি Activity (অ্যাপের একটি পর্দা) এই callback-গুলো পায়: onCreate (তৈরি), onStart (দেখা যাচ্ছে), onResume (সামনে, স্পর্শ নিচ্ছে), onPause (আংশিক ঢাকা পড়ছে), onStop (আর দেখা যাচ্ছে না), onDestroy (শেষ)। মূল নিয়ম: onStop-এর পরে প্রসেস যেকোনো মুহূর্তে বিনা সতর্কতায় মারা যেতে পারে, তাই দরকারি অবস্থা (অর্ধেক লেখা মেসেজ, ফর্মের তথ্য) আগেই সংরক্ষণ করতে হয়; ফিরলে অ্যাপ নতুন প্রসেসে জন্মে সেখান থেকে সাজিয়ে নেয়।

কাকে আগে মারা হবে, তা ঠিক হয় প্রসেসের importance দিয়ে। Android-এর ডকুমেন্টেশন মোটামুটি চারটি শ্রেণি বলে: foreground (যে অ্যাপ এখন সামনে, বা ব্যবহারকারী যার সাথে কাজ করছেন), visible (দেখা যাচ্ছে কিন্তু সামনে নয়, যেমন একটি dialog-এর পেছনের অ্যাপ), service (পেছনে কাজ করছে — গান বাজানোর মতো ব্যবহারকারীর টের পাওয়া কাজ হলে আরও উঁচুতে), আর cached (পেছনে বসে আছে, এখন কিছুই করছে না — শুধু পরে দ্রুত ফেরার জন্য রাখা)। system_server প্রতিটি অ্যাপ-প্রসেসের জন্য পর্ব ৩৮-এর oom_score_adj-এর মতো একটি সংখ্যা বসায় — যত বড়, তত আগে বলি। Android-এর source-এ সাধারণভাবে দেখা যায়: foreground ০, visible ১০০, perceptible (যেমন গান) ২০০, home ৬০০, previous (একটু আগে ব্যবহৃত) ৭০০, cached ৯০০–৯৯৯; আর গুরুত্বপূর্ণ সিস্টেম-প্রসেস ঋণাত্মক (মান সংস্করণভেদে বদলাতে পারে)।

পর্ব ৩৮-এর OOM killer আসে একেবারে শেষ মুহূর্তে, প্রায়ই thrashing-এ (পর্ব ৩৭) যন্ত্র জমে যাওয়ার পরে। lmkd আগেভাগে, চাপের লক্ষণ দেখেই, সবচেয়ে কম ক্ষতির প্রসেস সরায় — মোবাইলে একটি cached অ্যাপ হারানো তুচ্ছ, জমে থাকা পর্দা বড় ক্ষতি।

৫ · iOS-এর ভেতর — XNU, স্তর, অ্যাপের অবস্থা আর Jetsam

iOS, macOS, iPadOS, watchOS — Apple-এর সব OS-এর kernel একই: XNU (“X is Not Unix”). পর্ব ৬-এর hybrid kernel-এর এটি সবচেয়ে পরিচিত উদাহরণ। এর ভিত্তি Mach — ১৯৮০-এর দশকে Carnegie Mellon University-তে তৈরি একটি microkernel, যা task, thread, virtual memory আর message-ভিত্তিক IPC (Mach port) দেয়। তার পাশে, একই kernel address space-এ, বসানো BSD Unix-এর অংশ: প্রসেস, POSIX system call, ফাইল সিস্টেম, নেটওয়ার্ক stack, অনুমতি। আর driver লেখার জন্য C++-ভিত্তিক I/O Kit. অর্থাৎ নকশায় microkernel-এর ধারণা, কিন্তু গতির জন্য সব এক জায়গায়।

Apple-এর পুরোনো ডকুমেন্টেশন iOS-কে চারটি স্তরে বর্ণনা করত (এখন এই ভাগ কম ব্যবহৃত হয়, কিন্তু পরীক্ষায় ও বইয়ে প্রায়ই আসে):

অ্যাপের অবস্থা আর পেছনের কাজের সীমা

Apple-এর ডকুমেন্টেশনে একটি iOS অ্যাপের পাঁচটি অবস্থা: Not running (চলছে না), Inactive (সামনে, কিন্তু ঘটনা নিচ্ছে না — যেমন ফোন-কল আসার মুহূর্তে), Active (সামনে, স্বাভাবিক কাজ), Background (পেছনে, কিন্তু কোড চলছে) আর Suspended (মেমরিতে আছে, কিন্তু একটি নির্দেশও চলছে না)। হোম-এ গেলে অ্যাপ সাধারণত অল্প সময় Background-এ থেকে Suspended হয় — সব thread থামানো, তাই CPU বা ব্যাটারি খরচ নেই।

পেছনে কাজ চালাতে অ্যাপকে নির্দিষ্ট পথ নিতে হয়: চলতি কাজ শেষ করতে অল্প সময় চেয়ে নেওয়া, গান বাজানো, নেভিগেশন বা VoIP কলের মতো ঘোষিত background mode, OS-এর কাছে ডাউনলোড ছেড়ে দেওয়া (background URL session — OS নিজে ডাউনলোড করে, অ্যাপ ঘুমিয়ে থাকে), আর iOS 13 থেকে BackgroundTasks framework — অ্যাপ বলে “আমার একটি রিফ্রেশ দরকার”, কিন্তু কখন চলবে তা ঠিক করে OS, ব্যাটারি, নেটওয়ার্ক আর ব্যবহারকারীর অভ্যাস দেখে। Android-এর তুলনায় iOS এখানে বেশি কড়া।

Jetsam — swap ছাড়া মেমরি ব্যবস্থাপনা

পর্ব ৩০-এ উল্লেখ করা হয়েছে, iOS ক্লাসিক অর্থে অ্যাপের মেমরি flash-এ swap করে না (কিছু নতুন iPad-এ iPadOS 16 থেকে সীমিত swap এসেছে বলে জানা যায়)। RAM কমলে iOS ধাপে ধাপে এগোয়: প্রথমে কম ব্যবহৃত page চেপে ছোট করে রাখে (memory compression — macOS-এও OS X 10.9 থেকে আছে), অ্যাপকে memory warning পাঠায়, আর তাতেও না কুলালে Jetsam অগ্রাধিকারের ক্রমে প্রসেস বন্ধ করে — আগে Suspended আর পেছনের অ্যাপ, শেষে সামনের অ্যাপ। এছাড়া প্রতিটি অ্যাপের একটি সর্বোচ্চ মেমরির সীমা থাকে; সামনের অ্যাপও সেটি পার হলে Jetsam তাকে বন্ধ করে। ধারণা lmkd-এর মতোই: swap-এর বদলে কম দামি প্রসেস বন্ধ. Jetsam-এর ভেতরের সব খুঁটিনাটি Apple প্রকাশ করে না, তাই এই বিবরণ সরলীকৃত।

৬ · ব্যাটারির হিসাব — DVFS, governor, big.LITTLE, Doze আর wake lock

CMOS চিপের ট্রানজিস্টর প্রতিবার ০ থেকে ১-এ বদলালে একটু বিদ্যুৎ খায়। এই dynamic power-এর বহুল ব্যবহৃত মডেল:

এখানে C = চিপের সুইচ হওয়া মোট ধারকত্ব (capacitance), V = সরবরাহ ভোল্টেজ, f = clock frequency, আর α = প্রতি চক্রে কত অংশ ট্রানজিস্টর আসলে বদলায় (নিচে α-কে C-এর ভেতরে ধরে নেওয়া হলো)। এর পাশে আছে leakage power — চিপ চালু থাকলেই কিছু বিদ্যুৎ চুইয়ে যায়, কাজ না করলেও। মূল কৌশলটি হলো DVFS (dynamic voltage and frequency scaling): কাজ কম থাকলে frequency কমানো, আর তার সাথে ভোল্টেজও — কারণ কম frequency-তে ট্রানজিস্টর কম ভোল্টেজেও নির্ভরযোগ্যভাবে চলে। প্রতিটি চিপের কয়েকটি নির্দিষ্ট (frequency, voltage) জোড়া থাকে, যাদের বলে operating point.

কাজ-প্রতি শক্তির সূত্র — একটি ছোট প্রমাণ

একটি কাজে N টি CPU-চক্র লাগে। f frequency-তে সময় t = N / f. তাহলে dynamic শক্তি:

f বাদ পড়ে গেল! অর্থাৎ একটি নির্দিষ্ট কাজের dynamic শক্তি frequency-র ওপর নির্ভর করে না, নির্ভর করে শুধু V²-এর ওপর। শুধু frequency কমালে (ভোল্টেজ একই রেখে) power কমে, কিন্তু কাজটি দীর্ঘ হয় — শক্তি একই থাকে, আর সেই দীর্ঘ সময়ে leakage আরও বেশি খায়। লাভ আসে শুধু তখনই, যখন কম frequency ভোল্টেজও কমাতে দেয়।

Race-to-idle, নাকি ধীরে-স্থিরে?

উপরের সূত্র বলে ধীরে চালানো ভালো। কিন্তু চলার সময় মেমরি, bus আর অন্য অংশও জেগে থাকে, যাদের খরচ সময়ের সাথে বাড়ে। তখন উল্টো কৌশল জিততে পারে: race-to-idle — সর্বোচ্চ গতিতে কাজ শেষ করে পুরো চিপকে গভীর ঘুমে পাঠানো। কোনটি জেতে, তা সংখ্যার ওপর নির্ভর করে। নিচের ক্যালকুলেটরে একটি খেলনা মডেল (অনুমানগুলো কোডের মন্তব্যে লেখা) দিয়ে দুটি পরিস্থিতি তুলনা করুন।

// DVFS energy for ONE task of 2e9 CPU cycles that must finish within a 2 s window.
// Assumptions (toy numbers): P_dyn = C*V^2*f with C = 1 nF; leakage = 0.25 W * V
// while running; "rest of chip" (memory, buses) costs plat watts while the CPU runs;
// after the task the CPU sleeps at 0.02 W until the window ends.
const C = 1e-9, CYCLES = 2e9, WINDOW = 2.0, SLEEP = 0.02;
const points = [[2.0, 1.00], [1.5, 0.90], [1.0, 0.80], [1.0, 1.00]];   // [GHz, volts]
function energy(ghz, v, plat) {
  const f = ghz * 1e9, t = CYCLES / f;                  // run time in seconds
  const pDyn = C * v * v * f, pRun = pDyn + 0.25 * v + plat;
  return { t, pDyn, e: pRun * t + SLEEP * (WINDOW - t) };
}
const fx = (x, d) => x.toFixed(d);
const base = energy(2.0, 1.0, 0);
for (const plat of [0.1, 0.8]) {
  console.log("rest-of-chip power while running = " + plat + " W");
  for (const [g, v] of points) {
    const r = energy(g, v, plat);
    console.log("  " + fx(g, 1) + " GHz @ " + fx(v, 2) + " V: run " + fx(r.t, 2) + " s, P_dyn " +
      fx(r.pDyn, 3) + " W (x" + fx(r.pDyn / base.pDyn, 2) + "), total energy " + fx(r.e, 3) + " J");
  }
}

rest-of-chip power while running = 0.1 W
  2.0 GHz @ 1.00 V: run 1.00 s, P_dyn 2.000 W (x1.00), total energy 2.370 J
  1.5 GHz @ 0.90 V: run 1.33 s, P_dyn 1.215 W (x0.61), total energy 2.067 J
  1.0 GHz @ 0.80 V: run 2.00 s, P_dyn 0.640 W (x0.32), total energy 1.880 J
  1.0 GHz @ 1.00 V: run 2.00 s, P_dyn 1.000 W (x0.50), total energy 2.700 J
rest-of-chip power while running = 0.8 W
  2.0 GHz @ 1.00 V: run 1.00 s, P_dyn 2.000 W (x1.00), total energy 3.070 J
  1.5 GHz @ 0.90 V: run 1.33 s, P_dyn 1.215 W (x0.61), total energy 3.000 J
  1.0 GHz @ 0.80 V: run 2.00 s, P_dyn 0.640 W (x0.32), total energy 3.280 J
  1.0 GHz @ 1.00 V: run 2.00 s, P_dyn 1.000 W (x0.50), total energy 4.100 J

কে frequency বাছে — governor আর schedutil

Linux-এ DVFS-এর ব্যবস্থা cpufreq, আর কখন কোন frequency, তা ঠিক করে একটি নীতি — governor: performance (সবসময় সর্বোচ্চ), powersave (সর্বনিম্ন), ondemand (নিয়মিত বিরতিতে CPU-র ব্যস্ততা মেপে), আর আধুনিক Android ফোনে সাধারণত schedutil (Linux 4.7, ২০১৬ থেকে), যা সরাসরি scheduler-এর হিসাব করা প্রতিটি task-এর ব্যবহার (utilization) দেখে সিদ্ধান্ত নেয়। নিজের Linux ল্যাপটপে দেখতে পারেন (উদাহরণ; মান যন্ত্র আর driver-ভেদে আলাদা, আর Intel-এর intel_pstate-এ governor-এর তালিকা ছোট):

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq     # kHz
1804800

big.LITTLE: ২০১১ সালে ARM এই নকশা ঘোষণা করে — একই চিপে কয়েকটি বড়, দ্রুত কিন্তু বিদ্যুৎ-খেকো core আর কয়েকটি ছোট, ধীর কিন্তু সাশ্রয়ী core. পর্ব ২০-এ heterogeneous multiprocessing হিসেবে দেখেছেন। পেছনের সিঙ্ক ছোট core-এ, গেম বড় core-এ। Linux-এর Energy Aware Scheduling প্রতিটি core-এর শক্তি-মডেল দেখে task বসায়। ঠিক উপরের হিসাবের কারণে: ছোট core-এর C আর V দুটোই কম।

Doze, App Standby আর wake lock — অ্যাপকে ঘুম পাড়ানো

সবচেয়ে বড় শক্তির অপচয় প্রায়ই CPU-র গতি নয়, অকারণে জেগে থাকা। কয়েক বাইট পাঠাতেও মোবাইল রেডিও কয়েক সেকেন্ড উঁচু শক্তিতে থাকে; ২০টি অ্যাপ আলাদা সময়ে প্রতি কয়েক মিনিটে সার্ভারে খবর নিলে ফোন সারারাত প্রায় জেগেই থাকে। Android 6.0 এর জবাবে আনে Doze: ফোন চার্জে নেই, পর্দা বন্ধ আর নড়াচড়া নেই — কিছুক্ষণ এভাবে থাকলে OS অ্যাপের নেটওয়ার্ক, wake lock আর alarm স্থগিত রাখে, আর মাঝে মাঝে একটি ছোট “maintenance window”-তে সবার জমা কাজ একসাথে চালায়। পাশাপাশি App Standby: যে অ্যাপ ব্যবহারকারী অনেকদিন খোলেননি, তার পেছনের কাজ সীমিত; পরের সংস্করণে ব্যবহারের অভ্যাস দেখে অ্যাপকে কয়েকটি “bucket”-এ ভাগ করা হয়। জরুরি বার্তা আসে push notification-এর একটি সাধারণ চ্যানেলে। (নিয়ম সংস্করণভেদে বদলেছে; ডেভেলপাররা adb shell dumpsys deviceidle force-idle দিয়ে Doze জোর করে চালু করে অ্যাপ পরীক্ষা করেন।)

৭ · Embedded জগৎ — bare-metal superloop থেকে RTOS আর embedded Linux

সব যন্ত্রে OS লাগে না। Embedded সফটওয়্যারের একটি বর্ণালী আছে, আর কোনটি বাছবেন তা নির্ভর করে কাজের জটিলতা, deadline আর হার্ডওয়্যারের ওপর:

Superloop: কোনো OS নেই — main()-এর ভেতর একটি অসীম লুপ, যা পালাক্রমে প্রতিটি কাজের ফাংশন ডাকে। Interrupt এলে ছোট একটি ISR শুধু একটি পতাকা (flag) তোলে; লুপ ঘুরে সেই পতাকা দেখলে কাজটি করে। সহজ, ছোট, বোঝা যায় — কিন্তু সমস্যা: কোনো ফাংশন মাঝপথে থামানো যায় না। ধীর ফাংশন (পর্দা আঁকা, flash-এ লগ লেখা) চলার সময় জরুরি পতাকা পড়ে থাকে।

volatile bool urgent_flag = false;          /* set by the ISR, read by the loop */

void BUTTON_IRQHandler(void) { urgent_flag = true; clear_irq(); }   /* tiny ISR */

int main(void) {
    hardware_init();
    for (;;) {                               /* the superloop */
        if (sensor_due()) read_sensor();     /* 2 ms */
        if (urgent_flag) { urgent_flag = false; stop_motor(); }   /* 1 ms */
        update_display();                    /* 4 ms, cannot be interrupted by tasks */
        write_log();                         /* 3 ms */
    }
}

সবচেয়ে খারাপ ক্ষেত্রে কী হয়? পতাকা উঠল ঠিক যাচাইয়ের পরপরই। তখন অপেক্ষা: display ৪ + log ৩ + (পরের ঘোরার) sensor ২ + নিজের কাজ ১ = ১০ ms. সাধারণভাবে superloop-এ একটি ঘটনার worst-case response ≈ পুরো লুপের দৈর্ঘ্য (নিজের কাজসহ) — আর লুপে নতুন ফাংশন যোগ করলে প্রত্যেকের response বদলে যায়। এখন একই কাজ একটি preemptive RTOS-এ: priority urgent (৩) > sensor (২) > display/log (১)। ISR একটি semaphore দেয়, আর scheduler সাথে সাথে urgent task-কে চালায় — display মাঝপথে থামিয়ে। নিচের simulator দুটোকে একই ঘটনা-ক্রমে ১০০ ms চালায় (context switch আর ISR-এর খরচ শূন্য ধরা)।

// Superloop vs preemptive RTOS. 1 tick = 1 ms, 100 ms simulated, no overheads.
// sensor: every 10 ms, needs 2 ms | urgent IRQ work: 1 ms | display 4 ms, log 3 ms
const H = 100, irqAt = [3, 31, 48, 88];                        // sporadic interrupts
const sensorAt = Array.from({ length: 10 }, (_, k) => 10 * k);  // 0, 10, ..., 90
function superloop() {            // one loop: check sensor, check flag, display, log
  let t = 0, s = 0, i = 0; const rs = [], ri = [];
  while (t < H) {
    if (s < sensorAt.length && sensorAt[s] <= t) { t += 2; rs.push(t - sensorAt[s++]); }
    if (i < irqAt.length && irqAt[i] <= t) { t += 1; ri.push(t - irqAt[i++]); }  // ISR only set a flag
    t += 4 + 3;                                                 // display + log, never interrupted
  }
  return [rs, ri];
}
function rtos() {                 // priorities: urgent 3 > sensor 2 > display/log 1
  const rs = [], ri = [], sq = [], iq = [];                    // pending jobs [release, left]
  for (let t = 0; t < H; t++) {
    if (sensorAt.includes(t)) sq.push([t, 2]);
    if (irqAt.includes(t)) iq.push([t, 1]);                    // ISR gives a semaphore
    const q = iq.length ? iq : sq.length ? sq : null;          // highest ready task runs
    if (q && --q[0][1] === 0) (q === iq ? ri : rs).push(t + 1 - q.shift()[0]);
  }                                                             // otherwise background runs
  return [rs, ri];
}
for (const [name, [rs, ri]] of [["superloop", superloop()], ["RTOS     ", rtos()]]) {
  console.log(name + " sensor: " + rs.join(" ") + "  -> worst " + Math.max(...rs) + " ms");
  console.log(name + " urgent: " + ri.join(" ") + "  -> worst " + Math.max(...ri) + " ms");
}

superloop sensor: 2 9 8 7 7 6 6 5 4 3  -> worst 9 ms
superloop urgent: 7 7 9 6  -> worst 9 ms
RTOS      sensor: 2 2 2 3 2 2 2 2 2 2  -> worst 3 ms
RTOS      urgent: 1 1 1 1  -> worst 1 ms

পরিচিত কয়েকটি RTOS (সংক্ষেপে; মালিকানা ও লাইসেন্স সময়ের সাথে বদলেছে): FreeRTOS — Richard Barry-র শুরু করা ছোট, জনপ্রিয় kernel, ২০১৭ থেকে Amazon-এর তত্ত্বাবধানে, MIT লাইসেন্সে; Zephyr — Linux Foundation-এর open-source প্রকল্প (২০১৬ থেকে); VxWorks — Wind River-এর বাণিজ্যিক RTOS, মহাকাশযান আর বিমানে বহুল ব্যবহৃত (পর্ব ২৯-এর Mars Pathfinder-এর গল্প মনে করুন); QNX — একটি POSIX-ধাঁচের microkernel RTOS, ২০১০ থেকে BlackBerry-র, গাড়ির সফটওয়্যারে বিশেষভাবে পরিচিত; RTEMS — open-source, মূলত মহাকাশ ও বৈজ্ঞানিক যন্ত্রে।

Embedded Linux: MMU আর কয়েক দশ MB RAM থাকলে পুরো Linux চালানো যায় — নেটওয়ার্ক, ফাইল সিস্টেম, হাজারো driver তৈরি। তবে যন্ত্রের মাপে ছেঁটে বানানো image: Yocto Project (শিল্প-মানের build কাঠামো) বা Buildroot (সহজ, ছোট image). অনেক Wi-Fi রাউটারের ভেতরে Linux; OpenWrt সমর্থিত রাউটারে নির্মাতার পুরোনো firmware-এর বদলে হালনাগাদ open-source Linux চালাতে দেয়। সাধারণ Linux hard real-time নয়, তবে PREEMPT_RT প্যাচ (Linux 6.12 থেকে মূল kernel-এ যুক্ত বলে জানা যায়) দিয়ে latency অনেক কমানো যায়; অনেক যন্ত্রে দুটি মিলিয়ে নকশা হয় — Linux UI আর নেটওয়ার্ক সামলায়, পাশের একটি ছোট microcontroller-এ RTOS কঠিন deadline রক্ষা করে।

৮ · RTOS-এর ভেতর — tick, priority, নির্ধারিত latency আর ISR থেকে task-এ কাজ

একটি RTOS kernel সাধারণত কয়েক থেকে দশ KB-র — Linux-এর তুলনায় হাজার গুণ ছোট (memory footprint). এর মূল উপাদান:

• Fixed-priority preemptive scheduler: প্রতিটি task-এর অগ্রাধিকার ডেভেলপার আগেই ঠিক করেন (প্রায়ই পর্ব ২০-এর Rate Monotonic নিয়মে)। নিয়ম একটাই: ready task-দের মধ্যে সর্বোচ্চ অগ্রাধিকারেরটি চলে (সমানে ঐচ্ছিকভাবে round robin চলে)। CFS-এর মতো “ন্যায্যতা” নেই — নিচু task না-ও চলতে পারে, আর সেটাই ইচ্ছাকৃত।
• নির্ধারিত latency: scheduler-এর প্রতিটি কাজ (পরের task বাছা, ready তালিকায় যোগ) সীমিত, আগে থেকে জানা সময়ে শেষ হয় — যেমন প্রতিটি অগ্রাধিকারের আলাদা তালিকা আর একটি bitmap, যাতে সর্বোচ্চ ready task খুঁজতে কয়েকটি CPU নির্দেশই যথেষ্ট। এর নাম deterministic latency: গড়ে দ্রুত নয়, সবসময় একটি সীমার মধ্যে। তাই RTOS-এ dynamic memory (malloc) প্রায়ই এড়ানো হয় বা শুধু শুরুতে করা হয়।
• Tick আর tickless: একটি hardware timer নিয়মিত (যেমন প্রতি ১ ms) interrupt দেয় — system tick; kernel এতে সময় গোনে, delay শেষ হওয়া task জাগায়। কাজ না থাকলেও প্রতি ms-এ জাগা ব্যাটারির শত্রু, তাই tickless মোড: অলস হলে kernel হিসাব করে পরের task কখন জাগবে, timer সেই সময়ের জন্য বসিয়ে CPU-কে গভীর ঘুমে পাঠায় (FreeRTOS-এ configUSE_TICKLESS_IDLE; Linux-এও ২০০৭ সাল থেকে অলস CPU-তে tick বন্ধ রাখার ব্যবস্থা আছে)।
• Task-এর মধ্যে যোগাযোগ: queue (কপি করে বার্তা পাঠানো), semaphore (ঘটনার সংকেত), আর mutex — যাতে থাকে priority inheritance, পর্ব ২৯-এর priority inversion-এর প্রতিষেধক।

নিচে FreeRTOS-এর আসল API দিয়ে লেখা একটি ছোট নকশা (চালানো যাবে না — একটি microcontroller বোর্ড আর FreeRTOS লাগে; ফাংশনের নাম আর argument FreeRTOS-এর ডকুমেন্টেশন অনুযায়ী, read_sensor_i2c-এর মতো হার্ডওয়্যার-ফাংশন কাল্পনিক)। FreeRTOS-এ সংখ্যা বড় মানে অগ্রাধিকার বেশি, আর ০ হলো idle task-এর।

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"
#include "semphr.h"

static QueueHandle_t     xReadings;   /* sensor -> logger, 32 items        */
static SemaphoreHandle_t xBusMutex;   /* shared I2C bus, has priority inheritance */

static void vSensorTask(void *pv) {
    TickType_t xLast = xTaskGetTickCount();
    for (;;) {
        xSemaphoreTake(xBusMutex, portMAX_DELAY);
        int16_t v = read_sensor_i2c();
        xSemaphoreGive(xBusMutex);
        xQueueSend(xReadings, &v, 0);                  /* do not block if full */
        vTaskDelayUntil(&xLast, pdMS_TO_TICKS(10));    /* exact 10 ms period, no drift */
    }
}
static void vLoggerTask(void *pv) {
    int16_t v;
    for (;;)
        if (xQueueReceive(xReadings, &v, portMAX_DELAY) == pdPASS)
            write_to_flash(v);                          /* slow, low priority */
}
int main(void) {
    hardware_init();
    xReadings = xQueueCreate(32, sizeof(int16_t));
    xBusMutex = xSemaphoreCreateMutex();
    xTaskCreate(vSensorTask, "sensor", 256, NULL, 3, NULL);   /* stack in words, prio 3 */
    xTaskCreate(vLoggerTask, "logger", 512, NULL, 1, NULL);
    vTaskStartScheduler();                                    /* never returns normally */
    for (;;) {}
}

দুটি খুঁটিনাটি লক্ষ করুন। vTaskDelay(10) মানে এখন থেকে ১০ tick ঘুম — কাজের সময় যোগ হয়ে period ধীরে ধীরে সরে যায়; vTaskDelayUntil মানে শেষবার জাগার ঠিক ১০ ms পরে জাগা — নিয়মিত period. আর logger-এর portMAX_DELAY মানে ডেটা না আসা পর্যন্ত task blocked — CPU একটুও খায় না, idle task চলে, আর tickless মোডে চিপ ঘুমায়।

Interrupt latency আর ISR থেকে কাজ পাঠানো

পর্ব ৩৯-এ দেখেছেন, Linux interrupt-এর কাজ ভাগ করে: জরুরি অংশ (top half) সাথে সাথে, ভারী অংশ (bottom half) পরে। RTOS-এ একই নীতি আরও কড়া — deferred interrupt handling: ISR-এ শুধু হার্ডওয়্যার থেকে ডেটা নেওয়া আর একটি task-কে সংকেত দেওয়া; বাকি সব কাজ সেই task-এ, যার একটি স্পষ্ট অগ্রাধিকার আছে। কারণ ISR চলার সময় সমান বা নিচু interrupt আটকে থাকে, আর লম্বা ISR সবার interrupt latency বাড়ায় — hardware সংকেত দেওয়া থেকে handler শুরু হওয়া পর্যন্ত সময়, যা RTOS-এর বিজ্ঞাপনের মূল সংখ্যাগুলোর একটি। ISR-এর ভেতর থেকে শুধু ...FromISR নামের বিশেষ API ডাকা যায়, কারণ ISR কখনো block হতে পারে না।

1void vLogTask(void *p) {          /* prio 1 */2  for (;;) write_log_chunk();3}4void ADC_IRQHandler(void) {        /* ISR */5  BaseType_t woken = pdFALSE;6  xSemaphoreGiveFromISR(xSem, &woken);7  portYIELD_FROM_ISR(woken);8}9void vUrgentTask(void *p) {       /* prio 3 */10  for (;;) { xSemaphoreTake(xSem, portMAX_DELAY);11    stop_motor(); }12}

৯ · নিরাপত্তা-সনদ, IoT আর আপডেট — যন্ত্র যখন বছরের পর বছর চলে

Functional safety-র মানদণ্ড: যেখানে সফটওয়্যারের ভুলে মানুষ আহত হতে পারেন, সেখানে নিয়ন্ত্রক সংস্থা প্রমাণ চায় যে নকশা, কোড, পরীক্ষা আর পরিবর্তন একটি নির্দিষ্ট প্রক্রিয়ায় হয়েছে, আর প্রতিটি প্রয়োজন থেকে কোড ও পরীক্ষা পর্যন্ত চিহ্ন অনুসরণ করা যায়। পরিচিত তিনটি (সংক্ষেপে):

• DO-178C: বিমানের সফটওয়্যারের জন্য বহুল স্বীকৃত নির্দেশিকা (২০১১-এর দিকে প্রকাশিত, আগের DO-178B-র উত্তরসূরি)। ব্যর্থতার পরিণাম অনুযায়ী স্তর (Level A সবচেয়ে কঠোর), আর উঁচু স্তরে কোডের প্রতিটি শাখা পরীক্ষায় ছোঁয়ার প্রমাণ চায়।
• ISO 26262: সড়ক-যানের বৈদ্যুতিক ও ইলেকট্রনিক ব্যবস্থার functional safety. ঝুঁকি মেপে ASIL A থেকে D (D সবচেয়ে কঠোর, যেমন ব্রেক বা স্টিয়ারিং)।
• IEC 62304: চিকিৎসা-যন্ত্রের সফটওয়্যারের জীবনচক্রের মানদণ্ড; সম্ভাব্য ক্ষতি অনুযায়ী class A, B, C.

এখানে OS-এর আকার বড় প্রশ্ন: Linux-এর কয়েক কোটি লাইন এমন প্রমাণের আওতায় আনা প্রায় অসম্ভব, একটি ছোট RTOS kernel আনা যায়। তাই কয়েকটি বাণিজ্যিক RTOS (যেমন VxWorks, QNX, আর FreeRTOS-এর একটি নিরাপত্তা-সংস্করণ) এসব মানদণ্ডের জন্য প্রস্তুত “certification package” দেয় বলে বাজারজাত হয় — তবুও যন্ত্র-নির্মাতাকে নিজের পুরো সিস্টেমের প্রমাণ দিতে হয়।

IoT আর নিরাপত্তা-আপডেট: IoT (Internet of Things) মানে ইন্টারনেটে যুক্ত ছোট যন্ত্র — IP ক্যামেরা, স্মার্ট প্লাগ, রাউটার, শিল্প-সেন্সর। এরা প্রায়ই বছরের পর বছর একই firmware-এ চলে। ২০১৬ সালে Mirai নামের একটি ম্যালওয়্যার মূলত কারখানার ডিফল্ট পাসওয়ার্ড বদলানো হয়নি এমন লক্ষ লক্ষ ক্যামেরা আর রাউটার দখল করে বিশাল DDoS আক্রমণ চালায়। সুরক্ষা: প্রতিটি যন্ত্রের আলাদা পাসওয়ার্ড, অপ্রয়োজনীয় সেবা (Telnet ইত্যাদি) বন্ধ, স্বাক্ষর-যাচাই করা OTA আপডেট (পর্ব ৭ আর ৪৯-এর secure/verified boot-এর মতো, যাতে নকল firmware বসানো না যায়), আপডেট ব্যর্থ হলে আগের সংস্করণে ফেরার জন্য দুটি partition (A/B), আর নির্মাতার পক্ষ থেকে কত বছর প্যাচ দেওয়া হবে তার ঘোষণা। ব্যবহারকারী হিসেবে করণীয়: রাউটার ও ক্যামেরার পাসওয়ার্ড বদলানো, firmware হালনাগাদ রাখা, আর আপডেট থেমে যাওয়া যন্ত্রকে ইন্টারনেটে সরাসরি খোলা না রাখা।

১০ · AI-এর যুগে মোবাইল আর embedded কাজ — যাচাই না করলে বিপদ

Android API, FreeRTOS-এর configuration বা ব্যাটারির হিসাব — AI দ্রুত উত্তর দেয়, কিন্তু এখানে ভুলের দাম বেশি: মোবাইলে লক্ষ ফোনের ব্যাটারি, embedded-এ মাঠে বছরের পর বছর চলা একটি যন্ত্র, যার আপডেট কঠিন। সাধারণ ভুলগুলো:

AI-এর মোবাইল/embedded পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• যন্ত্র, চিপ, OS ও SDK-র সংস্করণ AI-কে জানিয়েছি আর উত্তর সেই সংস্করণের সাথে মিলিয়েছি
• API-র নাম আর argument অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি
• শক্তি বা worst-case সময়ের প্রতিটি সংখ্যা হাতে আবার হিসাব করেছি — AI-এর অঙ্ক নির্ভরযোগ্য নয়
• আসল যন্ত্রে মেপেছি: Android-এ batterystats / Perfetto, embedded-এ oscilloscope বা GPIO টগল করে latency
• ISR-এ blocking কল, malloc বা printf নেই; সব shared ডেটায় mutex বা queue
• নিরাপত্তা বন্ধ করার পরামর্শ (root, chmod 777, স্বাক্ষর-যাচাই বন্ধ, debug port খোলা) গ্রহণ করিনি
• চাপের মধ্যে পরীক্ষা করেছি — কম RAM-এর ফোন, Doze, দুর্বল নেটওয়ার্ক, বা সর্বোচ্চ interrupt-হার — শুধু “আমার যন্ত্রে চলে” নয়