ক্যাপাসিটি হল কোনও ডিভাইসের নির্দিষ্ট সময়ের মধ্যে থাকা কোনও রিসোর্সের (CPU, GPU ইত্যাদি) মোট পরিমাণ। এই পৃষ্ঠায় ক্যাপাসিটি-সম্পর্কিত জ্যাঙ্ক সমস্যা কীভাবে শনাক্ত ও সমাধান করতে হয় তা বর্ণনা করা হয়েছে।
গভর্নর ধীরে ধীরে প্রতিক্রিয়া জানাচ্ছেন
জ্যাঙ্ক এড়াতে, CPU ফ্রিকোয়েন্সি গভর্নরকে দ্রুত বার্স্ট ওয়ার্কলোডের উত্তর দিতে হবে। বেশিরভাগ UI অ্যাপ একই মৌলিক প্যাটার্ন অনুসরণ করে:
- ব্যবহারকারী স্ক্রিন পড়ছেন।
- ব্যবহারকারী স্ক্রিন টাচ করেন: কোনও বোতামে ট্যাপ করেন, স্ক্রল করেন ইত্যাদি।
- ইনপুটের উত্তরে স্ক্রিন স্ক্রল করে, অ্যাক্টিভিটি পরিবর্তন করে বা কোনওভাবে অ্যানিমেট করে।
- নতুন কন্টেন্ট দেখানোর সময় সিস্টেম শান্ত থাকে।
- ব্যবহারকারী স্ক্রিন পড়া চালিয়ে যান।
Pixel এবং Nexus ডিভাইস, টাচ বুস্ট প্রয়োগ করে টাচ করার সময় CPU ফ্রিকোয়েন্সি গভর্নর (এবং শিডিউলার) আচরণ পরিবর্তন করে। হাই ক্লক ফ্রিকোয়েন্সিতে (যা টাচ করার সময় ডিভাইসে ফ্রেম ড্রপ করতে পারে) ধীরে ধীরে র্যাম্প হওয়া এড়াতে, টাচ বুস্ট সাধারণত সিপিইউতে একটি ফ্রিকোয়েন্সি ফ্লোর সেট করে যাতে টাচ করার সময় প্রচুর সিপিইউ ক্যাপাসিটি উপলভ্য থাকে। টাচ করার পরে ফ্লোর কিছু সময় ধরে থাকে (সাধারণত প্রায় দুই সেকেন্ড)।
এছাড়াও, Pixel, Energy Aware Scheduling (EAS) দ্বারা প্রদত্ত schedtune cgroup-কে অতিরিক্ত টাচ বুস্ট সিগন্যাল হিসেবে ব্যবহার করে: টপ অ্যাপগুলিকে দ্রুত চালানোর জন্য পর্যাপ্ত CPU ক্যাপাসিটি আছে কিনা তা নিশ্চিত করতে schedtune-এর মাধ্যমে অতিরিক্ত ওয়েট দেওয়া হয়। Kryo CPU সহ Pixel-এর তুলনায় Nexus 5X এবং 6P-এর ছোট ও বড় CPU ক্লাস্টারের (যথাক্রমে A53 এবং A57) মধ্যে পারফর্ম্যান্সের অনেক বড় ব্যবধান রয়েছে। আমরা দেখেছি যে ছোট CPU ক্লাস্টার সবসময় মসৃণ UI রেন্ডারিংয়ের জন্য পর্যাপ্ত নয়, বিশেষ করে ডিভাইসে জিটারের অন্যান্য সোর্স থাকলে।
সেই অনুযায়ী, Nexus 5X ও 6P-তে, টাচ বুস্ট শিডিউলারের আচরণ পরিবর্তন করে যাতে ফোরগ্রাউন্ড অ্যাপগুলি বড় কোরে (এটি ধারণাগতভাবে CPU ফ্রিকোয়েন্সির ফ্লোরের মতো) যাওয়ার সম্ভাবনা বেশি থাকে। শিডিউলার পরিবর্তন না করে ফোরগ্রাউন্ড অ্যাপকে বড় CPU ক্লাস্টারে সরানোর সম্ভাবনা বাড়ালে, শিডিউলার বড় CPU কোরে থ্রেড লোড ব্যালেন্স করার সিদ্ধান্ত না নেওয়া পর্যন্ত ফোরগ্রাউন্ড অ্যাপের কাছে রেন্ডার করার জন্য পর্যাপ্ত CPU ক্ষমতা নাও থাকতে পারে। টাচ বুস্ট চলাকালীন শিডিউলারের আচরণ পরিবর্তন করার মাধ্যমে, UI থ্রেডকে অবিলম্বে একটি বড় কোরে চালানোর সম্ভাবনা বেশি থাকে এবং এটিকে সবসময় একটি বড় কোরে চালানোর জন্য বাধ্য না করে জ্যাঙ্ক এড়ানো যায়। এর ফলে পাওয়ার কনজাম্পশনের উপর গুরুতর প্রভাব পড়তে পারে।
থার্মাল থ্রটলিং
ডিভাইসকে সামগ্রিক থার্মাল আউটপুট কমাতে হলে থার্মাল থ্রটলিং হয়। এটি সাধারণত CPU, GPU ও DRAM ক্লক কমিয়ে করা হয়। আশ্চর্য হওয়ার কিছু নেই যে, এর ফলে প্রায়ই জাঙ্ক হয়, কারণ সিস্টেম হয়ত আর প্রদত্ত টাইম স্লাইসের মধ্যে রেন্ডার করার জন্য পর্যাপ্ত ক্যাপাসিটি প্রদান করতে পারে না। থার্মাল থ্রটলিং এড়ানোর একমাত্র উপায় হল কম পাওয়ার ব্যবহার করা। এটি করার অনেক উপায় নেই, তবে আগের SOC-এর সাথে আমাদের অভিজ্ঞতার ভিত্তিতে, আমাদের কাছে সিস্টেম ভেন্ডরদের জন্য কিছু সাজেশন আছে।
প্রথমত, আলাদা আলাদা CPU আর্কিটেকচার সহ নতুন SOC তৈরি করার সময়, CPU ক্লাস্টারের পারফর্ম্যান্স/W কার্ভ যেন ওভারল্যাপ করে তা নিশ্চিত করুন। সম্পূর্ণ প্রসেসরের সামগ্রিক পারফর্ম্যান্স/W কার্ভ একটি অবিচ্ছিন্ন লাইন হতে হবে। পারফরম্যান্স/W কার্ভে অবিচ্ছিন্নতা শিডিউলার এবং ফ্রিকোয়েন্সি গভর্নরকে অনুমান করতে বাধ্য করে যে একটি ওয়ার্কলোডের কী প্রয়োজন; জ্যাঙ্ক প্রতিরোধ করতে, শিডিউলার এবং ফ্রিকোয়েন্সি গভর্নর ওয়ার্কলোডকে প্রয়োজনের চেয়ে বেশি ক্ষমতা দেওয়ার ক্ষেত্রে ভুল করে। এর ফলে অনেক বেশি পাওয়ার খরচ হয়, যা থার্মাল থ্রটলিংয়ে অবদান রাখে।
দুটি CPU ক্লাস্টার সহ একটি কাল্পনিক SOC কল্পনা করুন:
- ছোট ক্লাস্টার, ক্লাস্টার ১, ক্লকের উপর নির্ভর করে থ্রুপুট বেঞ্চমার্কে ১০০-৩০০mW খরচ করতে পারে এবং ১০০-৩০০ স্কোর করে।
- ক্লাস্টার ২, বড় ক্লাস্টার, ১০০০ থেকে ১৬০০mW খরচ করতে পারে এবং ক্লকের উপর নির্ভর করে একই থ্রুপুট বেঞ্চমার্কে ৮০০ থেকে ১২০০ স্কোর করে।
এই বেঞ্চমার্কে, বেশি স্কোর মানে বেশি দ্রুত। ধীরগতির তুলনায় বেশি পছন্দসই না হলেও, দ্রুত গতির == বেশি বিদ্যুৎ খরচ।
শিডিউলার যদি মনে করে যে UI ওয়ার্কলোডের জন্য থ্রুপুট বেঞ্চমার্কে ৩১০ স্কোর প্রয়োজন, তাহলে জ্যাঙ্ক এড়ানোর জন্য সবচেয়ে ভালো উপায় হল সবচেয়ে কম ফ্রিকোয়েন্সিতে বড় ক্লাস্টার রান করা, যার ফলে অনেক পাওয়ার খরচ হয়। (এটি cpuidle আচরণ এবং আইডল হওয়ার জন্য রেসের উপর নির্ভর করে; SOC-এর সাথে একটানা পারফর্ম্যান্স/W কার্ভ অপ্টিমাইজ করা সহজ।)
দ্বিতীয়ত, cpusets ব্যবহার করুন। আপনার কার্নেল ও BoardConfig.mk-এ cpusets চালু করেছেন কিনা তা নিশ্চিত করুন।
এছাড়াও, আপনার ডিভাইস-নির্দিষ্ট init.rc-এ আপনাকে অবশ্যই আসল cpuset
অ্যাসাইনমেন্ট সেট-আপ করতে হবে। কিছু ভেন্ডর তাদের BSP-তে এটি বন্ধ করে দেয়, এই আশায় যে তারা শিডিউলারের আচরণকে প্রভাবিত করার জন্য
অন্যান্য ইঙ্গিত ব্যবহার করতে পারবে; আমাদের মনে হয় এটি যুক্তিযুক্ত নয়। CPU-এর মধ্যে লোড ব্যালেন্সিং এমনভাবে করা হয়েছে কিনা তা নিশ্চিত করার জন্য
cpusets কার্যকর, যা ডিভাইসটিতে ব্যবহারকারী আসলে কী করছেন তা প্রতিফলিত করে।
ActivityManager অ্যাপের আপেক্ষিক গুরুত্বের (শীর্ষ, ফোরগ্রাউন্ড, ব্যাকগ্রাউন্ড) উপর ভিত্তি করে বিভিন্ন সিপিউসেটে অ্যাপ অ্যাসাইন করে, যেখানে আরও গুরুত্বপূর্ণ অ্যাপগুলি সিপিইউ কোরে আরও বেশি অ্যাক্সেস পায়। এর ফলে ফোরগ্রাউন্ড ও টপ অ্যাপের জন্য পরিষেবার কোয়ালিটি নিশ্চিত করা যায়।
হোমোজেনিয়াস CPU কনফিগারেশনের ক্ষেত্রে cpusets কাজে লাগে, কিন্তু আপনাকে cpusets চালু না করে হেটেরোজেনিয়াস CPU কনফিগারেশন সহ ডিভাইস শিপ করা উচিত নয়। Nexus 6P হল একটি ভাল মডেল যা দেখায় কীভাবে হেটেরোজেনিয়াস CPU কনফিগারেশনে cpusets ব্যবহার করতে হয়; আপনার নিজের ডিভাইসের কনফিগারেশনের জন্য এটিকে ভিত্তি হিসেবে ব্যবহার করুন।
এছাড়াও, cpusets পাওয়ার সংক্রান্ত সুবিধা প্রদান করে, এর মাধ্যমে নিশ্চিত করা হয় যে পারফর্ম্যান্স-ক্রিটিক্যাল নয় এমন ব্যাকগ্রাউন্ড থ্রেডকে কখনও বড় CPU কোরে লোড ব্যালেন্স করা হয় না, যেখানে সেগুলি ব্যবহারকারীর অনুভূত সুবিধা ছাড়াই উল্লেখযোগ্যভাবে বেশি পাওয়ার খরচ করতে পারে। এটি থার্মাল থ্রটলিং এড়াতেও সাহায্য করতে পারে। থার্মাল থ্রটলিং হল একটি ক্ষমতা সংক্রান্ত সমস্যা, তবে থার্মাল থ্রটলিং হলে জিটার সংক্রান্ত উন্নতি UI পারফর্ম্যান্সের উপর অনেক বেশি প্রভাব ফেলে। কারণ, সিস্টেমটি 60FPS রেন্ডার করার ক্ষমতার কাছাকাছি চলবে, তাই ফ্রেম ড্রপ করার জন্য এটি কম জিটার নেয়।