اختبار أداء

يتضمن Android 8.0 اختبارات أداء Binder و hwbinder للإنتاجية ووقت الاستجابة. على الرغم من وجود العديد من السيناريوهات لاكتشاف مشاكل الأداء المحسوسة ، فإن تشغيل مثل هذه السيناريوهات قد يستغرق وقتًا طويلاً وغالبًا ما تكون النتائج غير متاحة إلا بعد تكامل النظام. يؤدي استخدام اختبارات الأداء المقدمة إلى تسهيل الاختبار أثناء التطوير واكتشاف المشكلات الخطيرة مسبقًا وتحسين تجربة المستخدم.

تشمل اختبارات الأداء الفئات الأربع التالية:

  • معدل نقل الرابط (متوفر في system/libhwbinder/vts/performance/Benchmark_binder.cpp )
  • زمن انتقال الرابط (متوفر في frameworks/native/libs/binder/tests/schd-dbg.cpp )
  • معدل نقل hwbinder (متوفر في system/libhwbinder/vts/performance/Benchmark.cpp )
  • زمن انتقال hwbinder (متوفر في system/libhwbinder/vts/performance/Latency.cpp )

حول الموثق و hwbinder

Binder و hwbinder عبارة عن بنى تحتية للاتصالات بين العمليات (IPC) تشترك في نفس برنامج تشغيل Linux ولكن مع الاختلافات النوعية التالية:

جانب الموثق hwbinder
غاية توفير مخطط IPC للأغراض العامة للإطار تواصل مع الأجهزة
ملكية محسن لاستخدام إطار عمل Android الحد الأدنى من الكمون المنخفض
تغيير سياسة الجدولة للمقدمة / الخلفية نعم رقم
مجادلات عابرة يستخدم التسلسل الذي يدعمه كائن الطرود يستخدم مخازن التبعثر ويتجنب الحمل الزائد لنسخ البيانات المطلوبة لتسلسل الطرود
الميراث ذو الأولوية رقم نعم

عمليات Binder و hwbinder

يعرض متخيل النظام المعاملات على النحو التالي:

الشكل 1. تصور النظام لعمليات الموثق.

في المثال أعلاه:

  • العمليات الأربعة (4) schd-dbg هي عمليات العميل.
  • عمليات الموثق الأربعة (4) هي عمليات الخادم (يبدأ الاسم بـ Binder وينتهي برقم تسلسلي).
  • يتم دائمًا إقران عملية العميل بعملية خادم مخصصة للعميل.
  • تتم جدولة جميع أزواج عملية الخادم والعميل بشكل مستقل بواسطة kernel بشكل متزامن.

في وحدة المعالجة المركزية 1 ، ينفذ نواة نظام التشغيل العميل لإصدار الطلب. ثم يستخدم نفس وحدة المعالجة المركزية كلما أمكن ذلك لإيقاظ عملية الخادم ومعالجة الطلب وتبديل السياق مرة أخرى بعد اكتمال الطلب.

الإنتاجية مقابل زمن الوصول

في معاملة مثالية ، حيث يتم تبديل عملية العميل والخادم بسلاسة ، لا ينتج عن اختبارات الإنتاجية والكمون رسائل مختلفة اختلافًا جوهريًا. ومع ذلك ، عندما يتعامل نظام التشغيل kernel مع طلب مقاطعة (IRQ) من الأجهزة ، أو في انتظار الأقفال ، أو ببساطة اختيار عدم التعامل مع رسالة على الفور ، يمكن أن تتشكل فقاعة زمن انتقال.

الشكل 2. فقاعة الكمون بسبب الاختلافات في الإنتاجية والكمون.

ينشئ اختبار الإنتاجية عددًا كبيرًا من المعاملات بأحجام حمولة مختلفة ، مما يوفر تقديرًا جيدًا لوقت المعاملة العادي (في أفضل السيناريوهات) والحد الأقصى للإنتاجية التي يمكن أن يحققها الموثق.

في المقابل ، لا ينفذ اختبار زمن الانتقال أي إجراءات على الحمولة لتقليل وقت المعاملة العادي. يمكننا استخدام وقت المعاملة لتقدير النفقات العامة للموثق ، وإجراء إحصائيات لأسوأ الحالات ، وحساب نسبة المعاملات التي يتوافق وقت الاستجابة معها مع الموعد النهائي المحدد.

معالجة الانقلابات ذات الأولوية

يحدث انعكاس الأولوية عندما ينتظر مؤشر ترابط ذي أولوية أعلى منطقيًا سلسلة رسائل ذات أولوية أقل. تحتوي تطبيقات الوقت الفعلي (RT) على مشكلة انعكاس ذات أولوية:

الشكل 3. انعكاس الأولوية في تطبيقات الوقت الفعلي.

عند استخدام جدولة Linux Completely Fair Scheduler (CFS) ، فإن الخيط لديه دائمًا فرصة للتشغيل حتى عندما تكون سلاسل الرسائل الأخرى ذات أولوية أعلى. ونتيجة لذلك ، فإن التطبيقات ذات جدولة CFS تتعامل مع انعكاس الأولوية كسلوك متوقع وليس كمشكلة. في الحالات التي يحتاج فيها إطار عمل Android إلى جدولة RT لضمان امتياز سلاسل الرسائل ذات الأولوية العالية ، ومع ذلك ، يجب حل انعكاس الأولوية.

مثال على انعكاس الأولوية أثناء معاملة Binder (تم حظر مؤشر ترابط RT منطقياً بواسطة سلاسل CFS الأخرى عند انتظار خدمة Binder للخدمة):

الشكل 4. انعكاس الأولوية ، سلاسل الرسائل المحظورة في الوقت الفعلي.

لتجنب العوائق ، يمكنك استخدام توريث الأولوية لتصعيد مؤشر ترابط Binder مؤقتًا إلى مؤشر ترابط RT عندما يقدم طلبًا من عميل RT. ضع في اعتبارك أن جدولة RT لها موارد محدودة ويجب استخدامها بعناية. في نظام مع n CPUs ، يكون الحد الأقصى لعدد سلاسل RT الحالية هو n أيضًا ؛ قد تحتاج خيوط RT الإضافية إلى الانتظار (وبالتالي تفوت المواعيد النهائية) إذا تم أخذ جميع وحدات المعالجة المركزية (CPU) بواسطة مؤشرات ترابط RT الأخرى.

لحل جميع الانعكاسات ذات الأولوية الممكنة ، يمكنك استخدام الوراثة ذات الأولوية لكل من Binder و hwbinder. ومع ذلك ، نظرًا لاستخدام Binder على نطاق واسع عبر النظام ، فإن تمكين الميراث ذي الأولوية لمعاملات Binder قد يرسل بريدًا عشوائيًا إلى النظام باستخدام خيوط RT أكثر مما يمكنه الخدمة.

إجراء اختبارات الإنتاجية

يتم تشغيل اختبار الإنتاجية مقابل معدل نقل معاملات Binder / hwbinder. في نظام لا يتم تحميله بشكل زائد ، تكون فقاعات زمن الانتقال نادرة ويمكن التخلص من تأثيرها طالما أن عدد التكرارات مرتفع بدرجة كافية.

  • يتم اختبار إنتاجية الرابط في system/libhwbinder/vts/performance/Benchmark_binder.cpp .
  • اختبار سرعة hwbinder موجود في system/libhwbinder/vts/performance/Benchmark.cpp .

نتائج الإختبار

مثال على نتائج اختبار الإنتاجية للمعاملات التي تستخدم أحجام حمولة مختلفة:

Benchmark                      Time          CPU           Iterations
---------------------------------------------------------------------
BM_sendVec_binderize/4         70302 ns      32820 ns      21054
BM_sendVec_binderize/8         69974 ns      32700 ns      21296
BM_sendVec_binderize/16        70079 ns      32750 ns      21365
BM_sendVec_binderize/32        69907 ns      32686 ns      21310
BM_sendVec_binderize/64        70338 ns      32810 ns      21398
BM_sendVec_binderize/128       70012 ns      32768 ns      21377
BM_sendVec_binderize/256       69836 ns      32740 ns      21329
BM_sendVec_binderize/512       69986 ns      32830 ns      21296
BM_sendVec_binderize/1024      69714 ns      32757 ns      21319
BM_sendVec_binderize/2k        75002 ns      34520 ns      20305
BM_sendVec_binderize/4k        81955 ns      39116 ns      17895
BM_sendVec_binderize/8k        95316 ns      45710 ns      15350
BM_sendVec_binderize/16k      112751 ns      54417 ns      12679
BM_sendVec_binderize/32k      146642 ns      71339 ns       9901
BM_sendVec_binderize/64k      214796 ns     104665 ns       6495
  • يشير الوقت إلى تأخير رحلة الذهاب والإياب المُقاس في الوقت الفعلي.
  • تشير وحدة المعالجة المركزية إلى الوقت المتراكم عند جدولة وحدات المعالجة المركزية للاختبار.
  • تشير التكرارات إلى عدد مرات تنفيذ وظيفة الاختبار.

على سبيل المثال ، لحمولة 8 بايت:

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

... يتم حساب الحد الأقصى من الإنتاجية التي يمكن أن يحققها الموثق على النحو التالي:

أقصى إنتاجية بحمولة 8 بايت = (8 * 21296) / 69974 ~ = 2.423 b / ns ~ = 2.268 Gb / s

خيارات الاختبار

للحصول على نتائج في .json ، قم بتشغيل الاختبار باستخدام الوسيطة --benchmark_format=json :

libhwbinder_benchmark --benchmark_format=json
{
  "context": {
    "date": "2017-05-17 08:32:47",
    "num_cpus": 4,
    "mhz_per_cpu": 19,
    "cpu_scaling_enabled": true,
    "library_build_type": "release"
  },
  "benchmarks": [
    {
      "name": "BM_sendVec_binderize/4",
      "iterations": 32342,
      "real_time": 47809,
      "cpu_time": 21906,
      "time_unit": "ns"
    },
   ….
}

إجراء اختبارات زمن الوصول

يقيس اختبار زمن الانتقال الوقت الذي يستغرقه العميل لبدء تهيئة المعاملة ، والتبديل إلى عملية الخادم للمعالجة ، واستلام النتيجة. يبحث الاختبار أيضًا عن سلوكيات جدولة سيئة معروفة يمكن أن تؤثر سلبًا على زمن انتقال المعاملة ، مثل برنامج الجدولة الذي لا يدعم توريث الأولوية أو يحترم علامة المزامنة.

  • اختبار وقت استجابة الموثق هو في frameworks/native/libs/binder/tests/schd-dbg.cpp .
  • اختبار زمن انتقال hwbinder موجود في system/libhwbinder/vts/performance/Latency.cpp .

نتائج الإختبار

تعرض النتائج (بتنسيق .json) إحصائيات لمتوسط ​​/ أفضل / أسوأ وقت استجابة وعدد المواعيد النهائية الفائتة.

خيارات الاختبار

تتخذ اختبارات وقت الاستجابة الخيارات التالية:

يأمر وصف
-i value حدد عدد التكرارات.
-pair value حدد عدد أزواج العملية.
-deadline_us 2500 حدد الموعد النهائي فينا.
-v الحصول على إخراج مطول (تصحيح الأخطاء).
-trace أوقف التتبع في الموعد النهائي.

توضح الأقسام التالية بالتفصيل كل خيار ، وتصف الاستخدام ، وتقدم أمثلة على النتائج.

تحديد التكرارات

مثال مع عدد كبير من التكرارات وإخراج مطوّل معطل:

libhwbinder_latency -i 5000 -pair 3
{
"cfg":{"pair":3,"iterations":5000,"deadline_us":2500},
"P0":{"SYNC":"GOOD","S":9352,"I":10000,"R":0.9352,
  "other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
},
"P1":{"SYNC":"GOOD","S":9334,"I":10000,"R":0.9334,
  "other_ms":{ "avg":0.19, "wst":2.9 , "bst":0.055, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":3.1 , "bst":0.066, "miss":1, "meetR":0.9998}
},
"P2":{"SYNC":"GOOD","S":9369,"I":10000,"R":0.9369,
  "other_ms":{ "avg":0.19, "wst":4.8 , "bst":0.055, "miss":6, "meetR":0.9988},
  "fifo_ms": { "avg":0.15, "wst":1.8 , "bst":0.067, "miss":0, "meetR":1}
},
"inheritance": "PASS"
}

تظهر نتائج الاختبار هذه ما يلي:

"pair":3
ينشئ زوجًا واحدًا من العميل والخادم.
"iterations": 5000
يتضمن 5000 تكرار.
"deadline_us":2500
الموعد النهائي هو 2500us (2.5 مللي ثانية) ؛ من المتوقع أن تلبي معظم المعاملات هذه القيمة.
"I": 10000
يتضمن تكرار الاختبار الفردي معاملتين (2):
  • معاملة واحدة حسب الأولوية العادية ( CFS other )
  • معاملة واحدة حسب أولوية الوقت الحقيقي ( RT-fifo )
5000 تكرار يساوي إجمالي 10000 معاملة.
"S": 9352
9352 من المعاملات تتم مزامنتها في نفس وحدة المعالجة المركزية.
"R": 0.9352
يشير إلى النسبة التي تتم بها مزامنة العميل والخادم معًا في نفس وحدة المعالجة المركزية.
"other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996}
الحالة المتوسطة ( avg ) ، والأسوأ ( wst ) ، وأفضل حالة ( bst ) لجميع المعاملات الصادرة عن المتصل ذي الأولوية العادي. هناك معاملتان miss الموعد النهائي ، مما يجعل نسبة الوفاء ( meetR ) 0.9996.
"fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
على غرار other_ms ، ولكن للمعاملات التي يصدرها العميل مع أولوية rt_fifo . من المحتمل (ولكن ليس مطلوبًا) أن fifo_ms لها نتيجة أفضل من other_ms ، بقيم avg ​​و wst أقل meetR أعلى (يمكن أن يكون الاختلاف أكثر أهمية مع التحميل في الخلفية).

ملاحظة: قد يؤثر تحميل الخلفية على نتيجة الإنتاجية ومجموعة other_ms في اختبار زمن الانتقال. يمكن فقط لـ fifo_ms إظهار نتائج مماثلة طالما أن تحميل الخلفية له أولوية أقل من RT-fifo .

تحديد قيم الزوج

يتم إقران كل عملية عميل مع عملية خادم مخصصة للعميل ، ويمكن جدولة كل زوج بشكل مستقل عن أي وحدة معالجة مركزية. ومع ذلك ، لا ينبغي أن يحدث ترحيل وحدة المعالجة المركزية أثناء المعاملة طالما كانت علامة SYNC honor .

تأكد من عدم تحميل النظام فوق طاقته! بينما يُتوقع زمن انتقال مرتفع في نظام محمّل فوق طاقته ، فإن نتائج الاختبار لنظام محمّل بشكل زائد لا توفر معلومات مفيدة. لاختبار نظام ذي ضغط أعلى ، استخدم -pair #cpu-1 (أو -pair #cpu بحذر). يؤدي الاختبار باستخدام -pair n مع n > #cpu إلى زيادة تحميل النظام وإنشاء معلومات غير مفيدة.

تحديد قيم الموعد النهائي

بعد اختبار سيناريو المستخدم الشامل (إجراء اختبار زمن الوصول على منتج مؤهل) ، قررنا أن 2.5 مللي ثانية هو الموعد النهائي للوفاء به. بالنسبة للتطبيقات الجديدة ذات المتطلبات الأعلى (مثل 1000 صورة / ثانية) ، ستتغير قيمة الموعد النهائي هذه.

تحديد الإخراج المطول

يؤدي استخدام الخيار -v إلى عرض الإخراج المطول. مثال:

libhwbinder_latency -i 1 -v

-------------------------------------------------- service pid: 8674 tid: 8674 cpu: 1 SCHED_OTHER 0
-------------------------------------------------- main pid: 8673 tid: 8673 cpu: 1 -------------------------------------------------- client pid: 8677 tid: 8677 cpu: 0 SCHED_OTHER 0
-------------------------------------------------- fifo-caller pid: 8677 tid: 8678 cpu: 0 SCHED_FIFO 99 -------------------------------------------------- hwbinder pid: 8674 tid: 8676 cpu: 0 ??? 99
-------------------------------------------------- other-caller pid: 8677 tid: 8677 cpu: 0 SCHED_OTHER 0 -------------------------------------------------- hwbinder pid: 8674 tid: 8676 cpu: 0 SCHED_OTHER 0
  • يتم إنشاء مؤشر ترابط الخدمة بأولوية SCHED_OTHER وتشغيله في CPU:1 مع pid 8674 .
  • ثم يبدأ المعاملة الأولى من قبل fifo-caller . لخدمة هذه المعاملة ، يقوم hwbinder بترقية أولوية الخادم ( pid: 8674 tid: 8676 ) إلى 99 ويميزها أيضًا بفئة جدولة عابرة (مطبوعة كـ ??? ). ثم يضع المجدول عملية الخادم في CPU:0 للتشغيل ومزامنتها مع نفس وحدة المعالجة المركزية مع عميلها.
  • طالب المعاملة الثاني له أولوية SCHED_OTHER . يعمل الخادم على إرجاع نفسه إلى إصدار سابق ويخدم المتصل بأولوية SCHED_OTHER .

باستخدام التتبع للتصحيح

يمكنك تحديد الخيار -trace لتصحيح أخطاء وقت الاستجابة. عند الاستخدام ، يوقف اختبار زمن الانتقال تسجيل tracelog في اللحظة التي يتم فيها اكتشاف زمن انتقال سيئ. مثال:

atrace --async_start -b 8000 -c sched idle workq binder_driver sync freq
libhwbinder_latency -deadline_us 50000 -trace -i 50000 -pair 3
deadline triggered: halt ∓ stop trace
log:/sys/kernel/debug/tracing/trace

يمكن أن تؤثر المكونات التالية على زمن الانتقال:

  • وضع بناء Android . عادةً ما يكون وضع Eng أبطأ من وضع Userdebug.
  • الإطار . كيف تستخدم خدمة إطار العمل ioctl الرابط؟
  • سائق الموثق . هل يدعم السائق قفل الحبيبات الدقيقة؟ هل يحتوي على كافة رقع تحول الأداء؟
  • إصدار Kernel . كلما كانت قدرة النواة في الوقت الحقيقي أفضل ، كانت النتائج أفضل.
  • تهيئة Kernel . هل يحتوي تكوين النواة على تكوينات DEBUG مثل DEBUG_PREEMPT و DEBUG_SPIN_LOCK ؟
  • جدولة Kernel . هل يحتوي kernel على برنامج جدولة مدرك للطاقة (EAS) أو جدولة معالجة متعددة غير متجانسة (HMP)؟ هل تؤثر أي برامج تشغيل kernel ( cpu-freq cpu-idle ، أو برنامج تشغيل وحدة المعالجة المركزية ، أو cpu-hotplug ، وما إلى ذلك) على المجدول؟