১৬ কেবি পৃষ্ঠার সাইজ

পৃষ্ঠার সাইজ হল গ্র্যানুলারিটি যার মাধ্যমে OS মেমরি ম্যানেজ করে। বর্তমানে বেশিরভাগ সিপিইউ ৪ কেবি পৃষ্ঠার সাইজ সাপোর্ট করে এবং তাই Android OS ও অ্যাপ ঐতিহাসিকভাবে ৪ কেবি পৃষ্ঠার সাইজের সাথে রান করার জন্য তৈরি ও অপ্টিমাইজ করা হয়েছে। ARM CPU-তে বড় ১৬ কেবি পেজ সাইজ কাজ করে এবং Android 15 থেকে শুরু করে, AOSP-তে ১৬ কেবি পেজ সাইজ সহ Android তৈরি করার সুবিধা আছে। এই বিকল্প অতিরিক্ত মেমরি ব্যবহার করে কিন্তু সিস্টেমের পারফর্ম্যান্স উন্নত করে। Android 15-এর ক্ষেত্রে, এই বিকল্পটি ডিফল্ট হিসেবে চালু করা নেই, তবে এটি ডেভেলপার মোড বা ডেভেলপার বিকল্প হিসেবে উপলভ্য, যাতে OEM এবং অ্যাপ ডেভেলপাররা ভবিষ্যতে সব জায়গায় ১৬ কেবি মোডে পরিবর্তন করার জন্য প্রস্তুত হতে পারেন।

Android 15 এবং তার পরবর্তী ভার্সনে ১৬ কেবি ELF অ্যালাইনমেন্ট সহ Android তৈরি করার সুবিধা আছে, যা ৪ কেবি এবং ১৬ কেবি কার্নেলের সাথে কাজ করে। এটি android14-6.1 থেকে শুরু হয়। ১৬ KB কার্নেলের সাথে ব্যবহার করা হলে, এই কনফিগারেশন অতিরিক্ত মেমরি ব্যবহার করে কিন্তু সিস্টেমের পারফর্ম্যান্স উন্নত করে।

Android-কে ১৬ কেবি-তে সেট করা

১৬ KB কার্নেল সহ arm64 টার্গেটে শুধুমাত্র ১৬ KB পৃষ্ঠা কাজ করে। তবে, Cuttlefish-এর জন্য x86_64-এ ১৬ কেবি ইউজারস্পেস সিমুলেট করার বিকল্পও আছে।

কার্নেল স্পেস

arm64 টার্গেটের জন্য, আপনি যদি কার্নেল তৈরি করতে Kleaf ব্যবহার করেন, তাহলে --page_size=16k ১৬ কেবি মোডে কার্নেল তৈরি করে। আপনি সরাসরি Linux কার্নেল কনফিগারেশন ব্যবহার করলে, CONFIG_ARM64_4K_PAGES-এর পরিবর্তে CONFIG_ARM64_16K_PAGES সেট করে ১৬ KB পৃষ্ঠা বেছে নিতে পারবেন।

প্রি-বিল্ট ১৬ কেবি জেনেরিক কার্নেল ইমেজ (GKI) বাইনারি, কাজ করে এমন ব্রাঞ্চ এবং রিলিজ ও রেস্পিন সংক্রান্ত বিবরণের জন্য, ১৬ কেবি GKI রিলিজ এবং GKI রিলিজ বিল্ড দেখুন।

ইউজার স্পেস

Android ইউজার স্পেসে ১৬ কেবি পৃষ্ঠা সাইজ সাপোর্ট চালু করতে, আপনার প্রোডাক্টে নিম্নলিখিত বিল্ড বিকল্প সেট করুন:

• PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true, PAGE_SIZE নির্ধারণ করা সরিয়ে দেয় এবং এটি রানটাইমে কম্পোনেন্টকে পৃষ্ঠার সাইজ নির্ধারণ করতে দেয়।
• PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384 যা নিশ্চিত করে যে প্ল্যাটফর্ম ELF ফাইলগুলি ১৬ KB অ্যালাইনমেন্টের সাথে তৈরি করা হয়েছে। ভবিষ্যতে মানানসই হওয়ার জন্য এই সাইজটি প্রয়োজনের চেয়ে বড়। ১৬ কেবি ELF অ্যালাইনমেন্টের মাধ্যমে, কার্নেল ৪ কেবি/১৬ কেবি পৃষ্ঠার সাইজ সাপোর্ট করতে পারে।

বিল্ড ফ্ল্যাগ যাচাই করা

lunch টার্গেট বেছে নেওয়ার পরে, এনভায়রনমেন্টে বিল্ড ফ্ল্যাগ সঠিকভাবে সেট-আপ করা হয়েছে কিনা তা যাচাই করুন:

$ source build/envsetup.sh
$ lunch target

$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
true

আগের দুটি কমান্ডের উত্তর হিসেবে যথাক্রমে 16384 ও true পেলে, বুঝতে হবে যে ১৬ KB কার্নেলের সাথে কাজ করার জন্য আপনার বিল্ড ফ্ল্যাগ সঠিকভাবে সেট-আপ করা হয়েছে। তবে, কোনও বিল্ড পাস করলেও, ১৬ কেবি এনভায়রনমেন্টে পার্থক্যের কারণে রানটাইম সংক্রান্ত সমস্যা হতে পারে।

১৬ কেবি পেজ সাইজ সিস্টেম প্রোগ্রামিং

Android-চালিত যেকোনও ডিভাইসের বেশিরভাগ কোড সরাসরি পৃষ্ঠার সাইজ নিয়ে কাজ করে না। তবে, পৃষ্ঠার সাথে সম্পর্কিত কোডের ক্ষেত্রে, কার্নেলের মেমরি অ্যালোকেশন সংক্রান্ত আচরণ পরিবর্তিত হয় এবং আপনাকে এমন কোড লিখতে হবে যা শুধুমাত্র মানানসই নয়, সর্বাধিক পারফর্ম্যান্স প্রদান করে এবং ন্যূনতম রিসোর্স ব্যবহার করে।

আপনি যদি ৪ কেবি সিস্টেমে ১ কেবি, ২ কেবি বা ৪ কেবি পর্যন্ত অঞ্চলে mmap কল করেন, তাহলে সিস্টেম এটি প্রয়োগ করার জন্য ৪ কেবি রিজার্ভ করে। অন্যভাবে বলতে গেলে, কার্নেল থেকে মেমরির অনুরোধ করার সময়, কার্নেলকে সবসময় অনুরোধ করা মেমরিকে নিকটতম পৃষ্ঠা সাইজে রাউন্ড আপ করতে হবে। যেমন, আপনি যদি ৪ কেবি অঞ্চলে ৫ কেবি অঞ্চল বরাদ্দ করেন, তাহলে কার্নেল ৮ কেবি বরাদ্দ করে।

১৬ KB কার্নেলে, পৃষ্ঠার এই অতিরিক্ত "শেষ অংশ" আরও বড় হয়। যেমন, ১ কেবি থেকে ৫ কেবি পর্যন্ত এইসব অ্যালোকেশন ১৬ কেবি কার্নেলের সাথে ব্যবহার করা হলে ১৬ কেবি অ্যালোকেট করবে। আপনি ১৭ কেবি অনুরোধ করলে, এটি ৩২ কেবি বরাদ্দ করে।

যেমন, ৪ কেবি সিস্টেমে, দুটি ৪ কেবি রিড-রাইট অ্যানোনিমাস অঞ্চল বরাদ্দ করা যেতে পারে। তবে, ১৬ KB কার্নেলে, এর ফলে দুটি পৃষ্ঠা বা ৩২ KB বরাদ্দ করা হবে। ১৬ KB কার্নেলে, সম্ভব হলে, এইসব অঞ্চলকে একটি রিড বা রাইটেবল পৃষ্ঠায় একত্রিত করা যেতে পারে যাতে শুধুমাত্র ১৬ KB ব্যবহার করা হয়, এর ফলে ৪ KB কার্নেলের তুলনায় ৮ KB জায়গা নষ্ট হয়। মেমরির ব্যবহার আরও কমাতে, আরও পৃষ্ঠা একত্রিত করা যেতে পারে। আসলে, সর্বাধিক অপ্টিমাইজ করা ১৬ কেবি সিস্টেমে, ১৬ কেবি পৃষ্ঠার জন্য ৪ কেবি সিস্টেমের তুলনায় কম মেমরি প্রয়োজন হয় কারণ একই মেমরির জন্য পৃষ্ঠার টেবিলের সাইজ এক-চতুর্থ হয়।

mmap ব্যবহার করার সময়, আপনি যে সাইজের অনুরোধ করছেন সেটি যেন নিকটতম পৃষ্ঠার সাইজের কাছাকাছি হয়। এটি নিশ্চিত করে যে কার্নেল যে পরিমাণ মেমরি বরাদ্দ করে তা রানটাইম ভ্যালুতে ব্যবহারকারীর স্পেসে সরাসরি দৃশ্যমান হয়, অন্তর্নিহিতভাবে অনুরোধ করা এবং অন্তর্নিহিতভাবে বা দুর্ঘটনাবশত অ্যাক্সেসযোগ্য হওয়ার পরিবর্তে।

১৬ কেবি ELF অ্যালাইনমেন্ট সহ শেয়ার করা লাইব্রেরি তৈরি করুন

Android প্রোজেক্টের অংশ হিসেবে শেয়ার করা লাইব্রেরি তৈরি করতে, ১৬ কেবি সাইজের পৃষ্ঠা চালু করুন বিকল্পে আগের সেটিংসই যথেষ্ট:

• PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
• PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384

Android প্রোজেক্টের অংশ নয় এমন শেয়ার করা লাইব্রেরি তৈরি করতে, আপনাকে এই লিঙ্কার ফ্ল্যাগ পাস করতে হবে:

-Wl,-z,max-page-size=16384

১৬ KB ELF অ্যালাইনমেন্টের জন্য বাইনারি ও প্রি-বিল্ট যাচাই করা

অ্যালাইনমেন্ট ও রানটাইম আচরণ যাচাই করার সবচেয়ে ভালো উপায় হল ১৬ কেবি কম্পাইল করা কার্নেলে টেস্ট ও রান করা। তবে, কিছু সমস্যা আগে থেকে ধরতে:

• Android 16 থেকে শুরু করে, আপনি বিল্ড টাইমে PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true সেট করতে পারবেন। সাময়িকভাবে এগুলি উপেক্ষা করতে Android.bp-এ ignore_max_page_size: true এবং Android.mk-এ LOCAL_IGNORE_MAX_PAGE_SIZE := true ব্যবহার করুন। এইসব সেটিংস সব প্রি-বিল্ট যাচাই করে এবং কোনও একটি আপডেট করা হলেও ১৬ কেবি অ্যালাইন করা না থাকলে, সেটি শনাক্ত করতে আপনাকে অনুমতি দেয়।

• আপনি atest elf_alignment_test রান করাতে পারবেন যা Android 15 ও এর পরের যেকোনও ভার্সনে লঞ্চ করা ডিভাইসে অন-ডিভাইস ELF ফাইলের অ্যালাইনমেন্ট যাচাই করে।