এসডিভি-তে পরিষেবার মান নির্ধারণ

এসডিভি কোয়ালিটি অফ সার্ভিস (কিউওএস) শিডিউলিং ফ্রেমওয়ার্কটি লাইফসাইকেল ম্যানেজার (এলএম) দ্বারা পরিচালিত সার্ভিস বান্ডেলগুলোর জন্য সুনির্দিষ্ট সিপিইউ রিসোর্স বরাদ্দ প্রদান করে। নিম্ন-স্তরের লিনাক্স শিডিউলিং অ্যাট্রিবিউটগুলোকে (পলিসি, প্রায়োরিটি, নাইস) লজিক্যাল প্রিসেটে রূপান্তরিত করার মাধ্যমে, এই প্ল্যাটফর্মটি সার্ভিস ডেভেলপমেন্ট এবং যানবাহন-ব্যাপী সিস্টেম টিউনিংয়ের মধ্যে একটি সুস্পষ্ট বিভাজন সম্ভব করে তোলে। এটি নিরাপত্তা-সংক্রান্ত এবং সময়-সংবেদনশীল ওয়ার্কলোডগুলোর জন্য প্রয়োজনীয় কম্পিউট ব্যান্ডউইথ সরবরাহ করতে সাহায্য করে, এবং একই সাথে সিস্টেমটি অস্থিতিশীলতা রোধ করার জন্য ব্যাকগ্রাউন্ড টাস্কগুলোকে নিয়ন্ত্রণ করে।

ভূমিকা ও দায়িত্ব

SDV শিডিউলিং মডেলটি একটি অর্পিত দায়িত্বের ধরণ অনুসরণ করে, যা সার্ভিসগুলোর বহনযোগ্যতা নিশ্চিত করতে সাহায্য করে এবং একই সাথে OEM-কে সিস্টেমটি টিউন করার সুযোগ দেয়।

প্রযুক্তিগত কর্মপ্রবাহ

1. প্ল্যাটফর্ম ইন্টিগ্রেশন: OEM যানবাহন-নির্দিষ্ট lifecycle_config.textproto ফাইলটি সংজ্ঞায়িত করে। এই ফাইলটি সিস্টেম-ব্যাপী শিডিউলিং প্রোফাইল (প্রিসেট) স্থাপন করে এবং টার্গেট হার্ডওয়্যারের উপর ভিত্তি করে সেগুলোকে সুনির্দিষ্ট লিনাক্স শিডিউলিং অ্যাট্রিবিউটের সাথে ম্যাপ করে।
2. সার্ভিস বান্ডেল তৈরি: ডেভেলপার তাদের APEX প্যাকেজের মধ্যে একটি scheduling_config.textproto বান্ডেল করেন, যেখানে একটি যৌক্তিক প্রিসেট (যেমন, ELEVATED ) সুপারিশ করা হয় এবং যেকোনো অভ্যন্তরীণ থ্রেডের নাম সংজ্ঞায়িত করা থাকে।
3. সার্ভিস বান্ডেল ইন্টিগ্রেশন: ভেহিকেল ইন্টিগ্রেশন পর্যায়ে, OEM ডেভেলপারের প্রস্তাবিত প্রিসেট পর্যালোচনা করে। APEX স্বাক্ষর করার আগে সামগ্রিক সিস্টেম স্থিতিশীলতা উন্নত করার জন্য OEM প্রস্তাবিত প্রোফাইলটি রাখতে পারে অথবা এটিকে ওভাররাইড করতে পারে, যেমন একটি ELEVATED সার্ভিসকে NORMAL এ ডাউনগ্রেড করা।
4. রানটাইম অ্যাট্রিবিউট রেজোলিউশন: যখন কোনো সার্ভিস চালু করা হয়, তখন LM সার্ভিসটির ম্যানিফেস্ট থেকে অনুমোদিত প্রিসেটটি শনাক্ত করে এবং OEM-এর সিস্টেম কনফিগারেশন থেকে সংশ্লিষ্ট লিনাক্স অ্যাট্রিবিউটগুলো সংগ্রহ করে।
5. স্টার্টআপ সিঙ্ক্রোনাইজেশন এবং প্রয়োগ: LM, সিগন্যাল-অ্যান্ড-কন্টিনিউ প্রোটোকল ব্যবহার করে সার্ভিস প্রসেসকে তার কার্যক্রম চালিয়ে যাওয়ার জন্য সংকেত দেওয়ার আগে, নির্ধারিত অ্যাট্রিবিউটগুলো সেটিতে প্রয়োগ করে।

মূল ধারণা

নিম্নলিখিত ধারণাগুলো এসডিভি সময়সূচী কাঠামোর কেন্দ্রবিন্দু।

সময়সূচী প্রিসেট

SDV-তে QoS পরিচালনার জন্য শিডিউলিং প্রিসেট হলো প্রধান পদ্ধতি। ডেভেলপাররা সরাসরি লিনাক্স শিডিউলিং প্যারামিটার সংজ্ঞায়িত করার পরিবর্তে, নামের মাধ্যমে পূর্বনির্ধারিত প্রিসেটগুলোকে উল্লেখ করেন। রান টাইমে, LM এই লজিক্যাল নামগুলোকে সুনির্দিষ্ট লিনাক্স শিডিউলিং অ্যাট্রিবিউটের সাথে ম্যাপ করে।

নিম্নলিখিত প্রিসেটগুলি lifecycle_config.textproto তে উদাহরণ হিসেবে কনফিগার করা হয়েছে:

একটি প্রিসেট প্রয়োগ করার সময়, LM প্রসেস-ব্যাপী nice ভ্যালু সেট করার জন্য setpriority সিস্টেম কলটি ব্যবহার করে। এটি ডিফল্ট লিনাক্স কমপ্লিটলি ফেয়ার শিডিউলার (CFS)-এর অধীনে কনটেনশনের সময় প্রসেসটির প্রাপ্ত আপেক্ষিক সিপিইউ শেয়ারকে প্রভাবিত করে।

বিশেষাধিকার এবং নিরাপত্তা

অননুমোদিত অগ্রাধিকার বৃদ্ধি রোধ করতে, SDV প্ল্যাটফর্মটি SELinux ডোমেইন এবং Linux ক্যাপাবিলিটির উপর ভিত্তি করে একটি স্তরভিত্তিক নিরাপত্তা মডেল ব্যবহার করে।

নিরাপত্তা ডোমেইন

• untrusted_service_bundle : স্ট্যান্ডার্ড প্রিসেটগুলির ( NORMAL , ELEVATED , IDLE ) জন্য ডিফল্ট ডোমেইন। কার্নেল এই ডোমেইনের প্রসেসগুলিকে সীমাবদ্ধ করে, যার ফলে তারা তাদের নিজস্ব শিডিউলিং প্যারামিটার পরিবর্তন করতে পারে না।
• priority_service_bundle : সিস্টেম-ব্যাপী lifecycle_config.textproto তে is_privileged: true সেট করা একটি প্রিসেট ব্যবহার করে যেকোনো সার্ভিস বান্ডেলকে এটি প্রদান করা হয়। এই ডোমেইনে স্থানান্তরিত হলে প্রসেসটি CAP_SYS_NICE ক্যাপাবিলিটি লাভ করে, যা এটিকে তার নিজস্ব রিসোর্স বরাদ্দ পরিচালনা করতে দেয়।

CAP_SYS_NICE সক্ষমতা

প্ল্যাটফর্মটি priority_service_bundle ডোমেইনের প্রসেসগুলোকে CAP_SYS_NICE ক্যাপাবিলিটি প্রদান করে। এই অনুমতি একটি প্রসেসকে নিম্নলিখিত কাজগুলো করার সুযোগ দেয়:

• এর নিজস্ব nice মূল্যকে এর প্রাথমিক নির্ধারিত সীমার ঊর্ধ্বে উন্নীত করুন।
• এর শিডিউলিং পলিসি পরিবর্তন করে SCHED_FIFO বা SCHED_RR মতো রিয়েল-টাইম ক্লাসে রূপান্তর করুন।
• sched_setaffinity ব্যবহার করে সিপিইউ অ্যাফিনিটি সেট করুন।
• SCHED_DEADLINE জন্য বিশেষায়িত ডেডলাইন প্যারামিটার কনফিগার করুন।

এই সক্ষমতাকে একটি নির্দিষ্ট ডোমেইনে সীমাবদ্ধ রাখলে, শুধুমাত্র সুস্পষ্টভাবে অনুমোদিত পরিষেবাগুলিতেই বিঘ্ন সীমিত হয় এবং এর মাধ্যমে সিস্টেম-ব্যাপী সময়সূচির ভারসাম্য সুরক্ষিত থাকে।

কনফিগারেশন গাইড

এই বিভাগে OEM এবং পরিষেবা ডেভেলপার উভয়ের জন্য কনফিগারেশন নির্দেশিকা প্রদান করা হয়েছে।

OEM নির্দেশিকা: সিস্টেম-ব্যাপী প্রিসেট

OEM /product/etc/lifecycle_config.textproto ফাইলে শিডিউলিং প্রোফাইল নির্ধারণ করে। প্ল্যাটফর্মটি lifecycle_management/config/lifecycle_config.textproto তে একটি উদাহরণ প্রদান করে, যা OEM-দের গাড়ির হার্ডওয়্যারের উপর ভিত্তি করে সামঞ্জস্য করতে হয়।

উদাহরণ: একটি রিয়েল-টাইম প্রিসেট সংজ্ঞায়িত করুন

একজন OEM নিরাপত্তা-সম্পর্কিত পরিষেবাগুলির জন্য একটি CRITICAL প্রিসেট নির্ধারণ করতে পারেন, যা সাধারণ অ্যাপ্লিকেশন দ্বারা কখনোই অগ্রাহ্য করা যাবে না:

# lifecycle_config.textproto
scheduling_presets {
  name: "CRITICAL"
  is_privileged: true
  thread_scheduling_configuration {
    policy: 1      # SCHED_FIFO
    priority: 80   # High real-time priority
  }
}

ডেভেলপার গাইড: সার্ভিস বান্ডেল কনফিগারেশন

সার্ভিস ডেভেলপাররা একটি scheduling_config.textproto ফাইলে পূর্বনির্ধারিত এবং ঐচ্ছিকভাবে লজিক্যাল থ্রেডের নাম নির্ধারণ করার পরামর্শ দেন। প্ল্যাটফর্মের কাছে শনাক্তযোগ্য হওয়ার জন্য, এই ফাইলের পাথটি অবশ্যই sdv_service_bundles_manifest.textproto ফাইলে রেজিস্টার করতে হবে।

উদাহরণ: ম্যানিফেস্ট নিবন্ধন

# sdv_service_bundles_manifest.textproto
service_bundle_entries {
  name: "SensorService"
  scheduling_config_path: "configs/scheduling_config.textproto"
}

উদাহরণ: একটি স্ট্যান্ডার্ড প্রিসেট ব্যবহার করুন

বেশিরভাগ পরিষেবার জন্য, scheduling_config.textproto তে একটি পূর্বনির্ধারিত নাম উল্লেখ করাই যথেষ্ট:

# configs/scheduling_config.textproto
scheduling_preset_name: "ELEVATED"

উদাহরণ: সার্ভিস-সৃষ্ট ওয়ার্কার থ্রেডের সময়সূচী নির্ধারণ

একজন সার্ভিস ডেভেলপার বিশেষায়িত কাজ, যেমন একটি লো-ল্যাটেন্সি সেন্সর ডেটা লুপ, পরিচালনা করার জন্য তাদের কোডে অতিরিক্ত ওয়ার্কার থ্রেড তৈরি করতে পারেন। ডেভেলপার কনফিগারেশন ফাইলে এই অভ্যন্তরীণ থ্রেডগুলির জন্য নামযুক্ত শিডিউলিং অ্যাট্রিবিউট নির্ধারণ করতে পারেন।

শুধুমাত্র সেইসব বিশেষাধিকারপ্রাপ্ত পরিষেবাগুলিতে ম্যানুয়াল অ্যাপ্লিকেশন ব্যবহার করুন, যেগুলি তাদের অভ্যন্তরীণ ওয়ার্কার থ্রেডগুলির জন্য প্রোপার্টি সেট করতে এই মেটাডেটা ব্যবহার করে:

# configs/scheduling_config.textproto
scheduling_preset_name: "CUSTOM"

# Map of logical thread names to their attributes (propagated as metadata)
thread_scheduling_configuration {
  key: "sensor-processing-thread"
  value {
    policy: 1        # SCHED_FIFO
    priority: 50
    cpu_affinity_ids: [2, 3]  # Pin to specific cores
  }
}

সিস্টেমের আচরণ এবং প্রয়োগ

যেকোনো পরিষেবা-নির্দিষ্ট কোড চালানোর আগে শিডিউলিং কনফিগারেশন সক্রিয় করতে SDV প্ল্যাটফর্ম একটি কঠোর প্রয়োগ পদ্ধতি ব্যবহার করে।

স্টার্টআপ সিঙ্ক্রোনাইজেশন

কোনো সার্ভিসকে ভুল প্রায়োরিটিতে চালু হওয়া থেকে বিরত রাখতে (এমনকি এর ইনিশিয়ালাইজেশন পর্যায়েও), LM এবং সার্ভিস বান্ডেল রানার (SBR) একটি সিগন্যাল-অ্যান্ড-কন্টিনিউ সিনক্রোনাইজেশন প্রোটোকল ব্যবহার করে:

1. প্রসেস তৈরি: LM, SBR প্রসেসটি ফোর্ক করে। এই পর্যায়ে, SBR চাইল্ড প্রসেসটি চলমান থাকে কিন্তু সাথে সাথেই একটি ব্লকড অবস্থায় প্রবেশ করে এবং তার stdin এ একটি সিগন্যালের জন্য অপেক্ষা করতে থাকে।
2. অ্যাট্রিবিউট প্রয়োগ: চাইল্ডটি ব্লক থাকা অবস্থায়, LM অনুরোধকৃত nice ভ্যালুটি প্রয়োগ করতে এবং শিডিউলিং পলিসি (যেমন, SCHED_IDLE ) কনফিগার করতে setpriority সিস্টেম কলটি ব্যবহার করে।
3. নিরাপত্তা স্থানান্তর: LM, SELinux ডোমেইন স্থানান্তর সম্পন্ন করে এবং চাইল্ডকে untrusted_service_bundle অথবা priority_service_bundle ডোমেইনের যেকোনো একটিতে স্থানান্তরিত করে।
4. সংকেত: সমস্ত প্যারামিটার সফলভাবে প্রয়োগ করার পরেই এলএম চাইল্ডের stdin এ একটি একক-বাইট সংকেত পাঠায়।
5. কার্য সম্পাদন: SBR সংকেতটি গ্রহণ করে সার্ভিস লাইব্রেরিগুলো লোড করা এবং লাইফসাইকেল মেথডগুলো কল করা শুরু করে।

প্রধান থ্রেড এবং জীবনচক্রের উপর প্রভাব

সার্ভিস লাইব্রেরিগুলো লোড করার আগে সিঙ্ক্রোনাইজ করার মাধ্যমে, প্ল্যাটফর্মটি সমস্ত লাইফসাইকেল কলব্যাক জুড়ে প্রধান এক্সিকিউশন থ্রেডের জন্য অনুরোধকৃত প্রায়োরিটি বজায় রাখে:

• onCreate : সমস্ত ডিপেন্ডেন্সি ইনজেকশন এবং প্রাথমিক রিসোর্স বরাদ্দ সঠিক প্রায়োরিটিতে সম্পন্ন হয়।
• onStart : এই প্রিসেটটি সক্রিয় অবস্থায় রূপান্তর এবং যেকোনো প্রাথমিক ওয়ার্ক লুপ নিয়ন্ত্রণ করে।
• onStop এবং onDestroy : শাটডাউনের সময় গুরুত্বপূর্ণ সিস্টেম কার্যক্রম যাতে ব্যাহত না হয়, তা প্রতিরোধ করার জন্য প্ল্যাটফর্মটি একই অগ্রাধিকারের ভিত্তিতে পরিষ্করণ কার্যক্রম সম্পাদন করে।

বাইন্ডার থ্রেড পুল এবং অগ্রাধিকার উত্তরাধিকার

প্ল্যাটফর্ম-পরিচালিত বাইন্ডার থ্রেড পুলের থ্রেডগুলো পুলটি তৈরি করা থ্রেডের প্রায়োরিটি নিয়ে কাজ সম্পাদন করে না। পরিবর্তে, সিনক্রোনাস ট্রানজ্যাকশনের ক্ষেত্রে, সার্ভার থ্রেড কলারের প্রায়োরিটি উত্তরাধিকার সূত্রে পায়। বাইন্ডার কার্নেল ড্রাইভার এই প্রায়োরিটি উত্তরাধিকার প্রক্রিয়াটি নিয়ন্ত্রণ করে।

থ্রেড-স্তরের সূক্ষ্ম সমন্বয়

যেসব সার্ভিস বান্ডেলের জন্য সূক্ষ্ম নিয়ন্ত্রণের প্রয়োজন হয় (যেমন, রিয়েল-টাইম প্রসেসিং লুপ), সেগুলোর ওয়ার্কার থ্রেডগুলিতে ম্যানুয়ালি কনফিগারেশন প্রয়োগ করতে হবে। থ্রেড-স্তরের কনফিগারেশন প্রয়োগ করতে নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. একটি প্রিভিলেজড প্রিসেটের জন্য অনুরোধ করুন (যেখানে is_privileged: true সেট করা আছে)।
2. thread_scheduling_configuration পড়ার জন্য sdv_service_bundles_scheduling লাইব্রেরির get_scheduling_configuration ফাংশনটি ব্যবহার করুন।
3. sched_setattr ব্যবহার করে ওয়ার্কার থ্রেডগুলিতে অ্যাট্রিবিউট প্রয়োগ করুন।

SELinux এবং সক্ষমতা প্রয়োগ

প্ল্যাটফর্মটি শিডিউলিং প্রিসেটগুলো কার্যকর করতে SELinux এবং CAP_SYS_NICE লিনাক্স ক্যাপাবিলিটি ব্যবহার করে:

• NORMAL বা IDLE মতো প্রিসেট ব্যবহারকারী সার্ভিসগুলোর জন্য, স্টার্টআপের সময় LM দ্বারা শিডিউলিং কনফিগার করা হয়। এই সার্ভিসগুলোর CAP_SYS_NICE ক্যাপাবিলিটি নেই এবং এরা তাদের প্রায়োরিটি বা পলিসি পরিবর্তন করতে পারে না।
• প্রিভিলেজড প্রিসেট ( is_privileged: true ) ব্যবহারকারী সার্ভিসগুলোকে CAP_SYS_NICE ক্যাপাবিলিটি প্রদান করা হয়। এটি তাদেরকে রিয়েল-টাইম টাস্কের জন্য প্রয়োজন অনুযায়ী তাদের অভ্যন্তরীণ থ্রেডগুলোর শিডিউলিং ম্যানুয়ালি নিয়ন্ত্রণ করার সুযোগ দেয়।

যাচাইকরণ এবং নমুনা

শিডিউলিং আচরণ যাচাই করার জন্য লগ বিশ্লেষণ এবং সিস্টেম-স্তরের কর্মক্ষমতা পরিমাপের সমন্বয় প্রয়োজন। এসডিভি প্ল্যাটফর্ম এই কৌশলগুলি প্রদর্শনের জন্য একটি বিশেষ নমুনা প্রদান করে।

QoS সময়সূচী নমুনা

samples/qos_scheduling এ অবস্থিত এই স্যাম্পলটিতে বেশ কয়েকটি পারফরম্যান্স-টেস্টিং সার্ভিস অন্তর্ভুক্ত রয়েছে, যেগুলো সমান্তরালভাবে চলার এবং তাদের অগ্রগতির প্রতিবেদন দেওয়ার জন্য ডিজাইন করা হয়েছে।

• PerformanceTesterNormal : NORMAL প্রিসেট দিয়ে চলে।
• PerformanceTesterElevated : ELEVATED প্রিসেট দিয়ে চলে।
• PerformanceTesterRealtime : এর অভ্যন্তরীণ ওয়ার্কার থ্রেডগুলিতে SCHED_FIFO প্রয়োগ করতে CUSTOM প্রিসেটটি ব্যবহার করে।
• PolicyOffender : একটি ডায়াগনস্টিক পরিষেবা যা একটি NORMAL প্রিসেট ব্যবহার করে রিয়েল-টাইম অগ্রাধিকার নির্ধারণের চেষ্টা করে। প্ল্যাটফর্মটি অননুমোদিত এস্কেলেশন সফলভাবে ব্লক করছে কিনা, তা যাচাই করার জন্য এটি ব্যবহৃত হয়।

যাচাইকরণ স্যুটটি চালান

1. QoS-নির্দিষ্ট অর্কেস্ট্রেশন কনফিগারেশন সক্রিয় করুন:

   adb shell setprop persist.sdv.orchestrator_config_path /etc/orch/vm_qos_scheduling_orch_config.textproto

2. সার্ভিসগুলোকে তাদের নিজ নিজ শিডিউলিং ডোমেইনে চালু করতে ডিভাইসটি রিবুট করুন:

   adb reboot

3. তুলনামূলক পারফরম্যান্সের ফলাফল দেখতে লগগুলো ফিল্টার করুন:

   adb logcat | grep sdv_sample_qos_common

   PerformanceTesterElevated সার্ভিসটি PerformanceTesterNormal এর তুলনায় উল্লেখযোগ্যভাবে বেশি ওয়ার্ক ইউনিট সম্পন্ন হওয়ার রিপোর্ট করে। PolicyOffender সার্ভিসের লগগুলিতে EPERM বা SELinux ডিনায়াল এররগুলো অন্তর্ভুক্ত থাকে।

পশ্চাৎ সামঞ্জস্যতা

• পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্যতা বজায় রাখার জন্য, যে কোনো লিগ্যাসি সার্ভিস বান্ডেল যা তার ম্যানিফেস্টে একটি scheduling_config_path নির্দিষ্ট করে কিন্তু কনফিগারেশন ফাইলে কোনো scheduling_preset_name নির্দিষ্ট করে না , সেটিকে স্বয়ংক্রিয়ভাবে একটি প্রিভিলেজড সার্ভিস হিসেবে গণ্য করা হয়। এটি সেইসব পুরোনো সার্ভিসের জন্য প্রয়োজনীয় ক্যাপাবিলিটি (যেমন, CAP_SYS_NICE ) সংরক্ষণ করে, যেগুলো ম্যানুয়াল থ্রেড টিউনিংয়ের উপর নির্ভর করে।
• ভবিষ্যতের কোনো রিলিজে রুট কনফিগারেশন মেসেজ DeadlineSchedulingConfiguration এর নাম পরিবর্তন করার কথা রয়েছে। বর্তমান নামটি পুরোনো এবং এটি আর সঠিকভাবে প্রতিফলিত করে না যে মেসেজটি শুধু ডেডলাইন শিডিউলিং নয়, বরং সব ধরনের শিডিউলিং পরিচালনা করে।