اختبار الأداء

يتضمن Android 8.0 اختبارات أداء المجلِّد و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 هما بروتوكول الاتصال بين العمليات في Android (IPC). بُنى أساسية تشترك في برنامج تشغيل Linux نفسه ولكنها تتضمن ما يلي الاختلافات النوعية:

عمليتا الربط والدمج

يعرض أداة عرض systrace المعاملات على النحو التالي:

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

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

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

سرعة معالجة البيانات مقابل وقت الاستجابة

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

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

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

التعامل مع عمليات قلب الأولوية

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

عند استخدام جدولة برنامج جدولة التسليم العادل (CFS) لنظام التشغيل Linux، فإن سلسلة التعليمات يمكن تنفيذ هذه الخطوة حتى عندما تكون سلاسل المحادثات الأخرى ذات أولوية أعلى. وبالتالي تطبيقات عكس أولوية التعامل مع أولوية معالجة جدولة خدمات ملفات تعريف الارتباط (CFS) كسلوك متوقع وليس كمشكلة. الحالات التي يحتاج فيها إطار عمل Android إلى جدولة استخدام ميزة "المراسلة النصية في الوقت الفعلي" لضمان امتياز سلاسل المحادثات ذات الأولوية العالية، إلا أنّ عكس الأولوية يجب حلها.

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

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

لحل جميع عمليات عكس الأولويات المحتملة، يمكنك استخدام الأولوية الوراثة لكل من المرابط وhwbinder. ورغم ذلك، يستخدم المجلَّد على نطاق واسع عبر النظام، فقد يؤدي تمكين اكتساب الأولوية لمعاملات المربط إرسال محتوى غير مرغوب فيه إلى النظام باستخدام سلاسل محادثات RT أكثر مما يمكنه خدمته.

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

يتم إجراء اختبار سرعة معالجة البيانات مقابل سرعة معالجة معاملات binder/hwbinder. ضِمن لا يتحمّل أي عبء زائد، ومن النادر أن تحدث فقاعات وقت الاستجابة. ما دام عدد التكرارات مرتفعًا بما يكفي.

• بدأ اختبار سرعة معالجة بيانات binder 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

• الوقت يشير إلى تأخر رحلة الذهاب والعودة الذي يتم قياسه في الوقت الفعلي.
• تشير وحدة المعالجة المركزية (CPU) إلى الوقت المتراكمة عند جدولة وحدات المعالجة المركزية (CPU). للاختبار.
• تشير التكرارات إلى عدد مرات دالة الاختبار وتنفيذه.

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

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

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

الحد الأقصى لسرعة معالجة البيانات مع حمولة 8 بايت = (8 * 21296)/69974 ~= 2.423 b/ns ~= 2.268 غيغا بايت/ثانية

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

للحصول على نتائج بتنسيق 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.) إحصاءات لمتوسط/أفضل/أسوأ وقت الاستجابة عدد المواعيد النهائية الفائتة.

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

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

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

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

مثال يحتوي على عدد كبير من التكرارات والنتائج المطوَّلة غير مفعَّلة:

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

تتضمّن 5,000 تكرار.

"deadline_us":2500

الموعد النهائي هو 2500us (2.5 ملي ثانية)؛ فمن المتوقع أن تلبي معظم المعاملات هذا

"I": 10000

يتضمن التكرار التجريبي الواحد معاملتين (2):

• معاملة واحدة حسب الأولوية العادية (CFS other)
• معاملة واحدة حسب الأولوية في الوقت الفعلي (RT-fifo)

5000 تكرار يساوي إجمالي 10,000 معاملة.

"S": 9352

تمت مزامنة 9352 معاملة في وحدة المعالجة المركزية نفسها.

"R": 0.9352

تشير إلى النسبة التي تتم بها مزامنة البرنامج والخادم معًا في نفس وحدة المعالجة المركزية (CPU).

"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.

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

تقترن كل عملية من عمليات العميل بعملية خادم مخصصة لهذا العميل، ويمكن جدولة كل زوج من الأجهزة على حدة على أي وحدة معالجة مركزية (CPU). إلا أن وحدة المعالجة المركزية (CPU) ينبغي ألا يحدث نقل البيانات أثناء أي معاملة طالما أن علامة 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 لتصحيح الأخطاء في وقت الاستجابة. فعندما فإن اختبار وقت الاستجابة يوقف تسجيل سجل التتبع في الوقت الذي يكون فيه يتعذر وقت الاستجابة. مثال:

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: عادةً ما يكون الوضع الهندسي أبطأ من وضع تصحيح أخطاء المستخدم.
• إطار العمل: كيف تستخدم خدمة إطار العمل هل تريد ioctl للضبط على مادة الربط؟
• برنامج تشغيل Binder. هل يدعم السائق البيانات الدقيقة؟ قفلها؟ هل يحتوي على جميع رموز تصحيح الأداء؟
• إصدار النواة: إمكانات أفضل للنواة في الوقت الفعلي كانت النتائج أفضل.
• إعداد النواة: هل تحتوي تهيئة النواة على بإعدادات DEBUG مثل DEBUG_PREEMPT DEBUG_SPIN_LOCK؟
• أداة جدولة النواة: هل تحتوي النواة على وعي بالطاقة أداة جدولة المهام (EAS) أو أداة جدولة عمليات المعالجة غير المتجانسة (HMP)؟ استخدام أي نواة السائقون (سائق واحد (cpu-freq)، سائق واحد (cpu-idle)، cpu-hotplug وما إلى ذلك) في أداة الجدولة؟