أداة تحليل الطاقة/الأداء المفتوحة (OPPAT)
جدول المحتويات
- مقدمة
- أنواع البيانات المدعومة
- تصور الأوبات
- ميزات الرسم البياني
- أنواع المخططات
- جمع البيانات لـ OPPAT
- دعم بيانات PCM
- بناء الأوامر
- تشغيل Oppat
- الأحداث المشتقة
- باستخدام واجهة واجهة المستخدم الرسومية Browswer
- القيود
مقدمة
أداة تحليل الطاقة/الأداء المفتوحة (OPPAT) هي أداة تحليل الطاقة والمعمارية عبر الهندسة المعمارية.
- المتقاطع: يدعم ملفات TRACE Windows ETW وملفات TRACE Linux/Android Perf/Trace CMD
- البنية المتقاطعة: يدعم أحداث أجهزة Intel و ARM (باستخدام Perf و/أو PCM)
صفحة ويب المشروع هي https://patinnc.github.io
رمز المصدر repo هو https://github.com/patinnc/oppat
لقد أضفت نظام تشغيل (OS_VIEW) إلى ميزة مخطط كتلة وحدة المعالجة المركزية. هذا يعتمد على صفحات بريندان جريج مثل http://www.brendangregg.com/linuxperf.html. فيما يلي بعض بيانات المثال لتشغيل إصدار قديم من Geekbench v2.4.2 (رمز 32 بت) على ARM 64bit Ubuntu Mate v18.04.2 Raspberry Pi 3 B+، 4 Arm Cortex A53 CPU:
- مقطع فيديو للتغييرات على مخطط كتلة وحدة المعالجة المركزية OS_VIEW و ARM A53 يعمل على تشغيل GEEKBENCH:
- هناك بعض الشرائح التمهيدية لمحاولة شرح تخطيط OS_VIEW و CPU_DIAGRAM ثم شريحة واحدة توضح النتائج لكل من الاختبارات الثلاثين
- ملف Excel للبيانات في الفيلم: ملف Excel من Geekbench الفيلم
- HTML من البيانات في الفيلم ... انظر Geekbench v2.4.2 على 4 Core Arm Cortext A53 مع OS_VIEW ، مخطط وحدة المعالجة المركزية.
- لوحة القيادة PNG لجميع المراحل الثلاثين التي تم فرزها عن طريق زيادة التعليمات/ثانية ... انظر ARM Cortex A53 Raspberry PI 3 مع لوحة معلومات رقاقة CPU 4-Core التي تعمل على تشغيل Geekbench.
فيما يلي بعض بيانات مثال لتشغيل معيار تدور (اختبارات عرض النطاق الترددي للذاكرة/ذاكرة التخزين المؤقت ، اختبار "تدور" Keep-CPU-busy) على وحدات المعالجة المركزية Raspberry PI 3 B+ (Cortex A53):
- مقطع فيديو للتغييرات على OS_VIEW و ARM A53 CPU BLOCK DIAGRAM RENFRENT:
- هناك بعض الشرائح التمهيدية لمحاولة شرح مخططات OS_VIEW وتخطيط CPU_Diagram ، وهي شريحة تظهر في أي وقت (بالثواني) يتم عرض كل اختبار فرعي (حتى تتمكن
- ملف Excel للبيانات في الفيلم: ملف Excel من Geekbench الفيلم
- HTML من البيانات في الفيلم ... انظر ARM Cortex A53 Raspberry PI 3 مع مخطط وحدة المعالجة المركزية 4-Core Chip Running SPENMARK.
- لوحة القيادة PNG لجميع المراحل الخمس التي تم فرزها عن طريق زيادة التعليمات/ثانية ... انظر ARM Cortex A53 Raspberry PI 3 مع مخطط وحدة المعالجة المركزية 4-Core رقاقة تشغيل تشغيل الدوران.
فيما يلي بعض البيانات على تشغيل Geekbench على وحدات المعالجة المركزية Haswell:
- مقطع فيديو للتغييرات على مخطط كتلة OS_View و Haswell CPU Raching Geekbench:
- هناك بعض الشرائح التمهيدية لمحاولة شرح مخططات OS_VIEW وتخطيط CPU_Diagram ، وهي شريحة تظهر في أي وقت (بالثواني) يتم عرض كل اختبار فرعي (حتى تتمكن
- ملف Excel للبيانات في الفيلم: ملف Excel من Geekbench الفيلم
- HTML للبيانات في الفيلم ... انظر Intel Haswell مع مخطط وحدة المعالجة المركزية 4-CPU شريحة Geekbench.
- لوحة القيادة PNG لجميع المراحل الخمسين مرتبة عن طريق زيادة UOPS متقاعد/ثانية ... انظر لوحة معلومات Intel Haswell مع لوحة معلومات CPU 4-Core التي تعمل على تشغيل Geekbench.
فيما يلي بعض البيانات لتشغيل معيار "الدوران" الخاص بي مع 4 اختبارات فرعية على وحدات المعالجة المركزية Haswell:
- الاختبار الفرعي الأول هو اختبار عرض النطاق الترددي للذاكرة. يتم استخدام كتلة L2/L3/الذاكرة بشكل كبير وتتوقف أثناء الاختبار. الفئران UOPS/CYCLE منخفضة لأن الفئران متوقفة في الغالب.
- الاختبار الفرعي الثاني هو اختبار عرض النطاق الترددي L3. الذاكرة BW الآن منخفضة. يتم استخدام كتلة L2 و L3 بشكل كبير وتتوقف أثناء الاختبار. الفئران UOPS/CYCLE أعلى لأن الفئران أقل توقف.
- الاختبار الفرعي الثالث هو اختبار عرض النطاق الترددي L2. L3 والذاكرة BW منخفضة الآن. يتم استخدام كتلة L2 عالية وتتوقف أثناء الاختبار. تعتبر UOPS/Cycle أعلى لأن الفئران أقل توقفًا.
- الاختبار الفرعي الرابع هو اختبار تدور (مجرد إضافة حلقة). يقع L2 و L3 والذاكرة BW بالقرب من الصفر. تقع الدورة/الدورة الفئران حوالي 3.3 UOPS/CYCLE التي تقترب من 4 UOPS/CYCLE MAX ممكنة.
- مقطع فيديو للتغييرات في مخطط Haswell CPU Block الذي يعمل "تدور" مع التحليل. يرى
- ملف Excel للبيانات في الفيلم: ملف Excel من تدور الفيلم
- HTML من البيانات في الفيلم ... انظر Intel Haswell مع مخطط وحدة المعالجة المركزية 4-CPU شريحة تشغيل الدوران.
إن intel haswell مع مجموعات بيانات مخطط وحدة المعالجة المركزية مخصصة لرقاقة Intel 4-CPU ، و Linux OS ، وملف HTML مع أحداث 50+ HW عبر أخذ العينات perf وغيرها من البيانات التي تم جمعها. ميزات CPU_Diagram:
- ابدأ بمخطط كتلة SVG من wikichip.org (يستخدم بإذن) ،
- انظر إلى قيود الموارد (مثل Max BW ، بايت/بايت كحد أقصى على المسارات المختلفة ، الحد الأدنى من الدورات/UOP ، إلخ) ،
- حساب المقاييس لاستخدام الموارد
- فيما يلي جدول لاختبار عرض النطاق الترددي الذي يعرض معلومات استخدام الموارد في جدول (إلى جانب تقدير ما إذا كانت وحدة المعالجة المركزية متوقفة بسبب الاستخدام). يحتوي جدول HTML (ولكن ليس PNG) على معلومات منبثقة عندما تحوم على الحقول. يوضح الجدول أن:
- يتم توقف النواة على عرض النطاق الترددي للذاكرة بنسبة 55 ٪ من الحد الأقصى الممكن 25.9 جيجابايت/ثانية. إنه اختبار ذاكرة BW
- Superqueue (SQ) ممتلئ (54.5 ٪ لـ Core0 و 62.3 ٪ Core1) من الدورات (لذلك لا يمكن التعامل مع المزيد من طلبات L2)
- المخزن المؤقت لملء الخط FB ممتلئ (30 ٪ و 51 ٪) بحيث لا يمكن نقل الخطوط إلى L1D من L2
- والنتيجة هي أن الواجهة الخلفية متوقفة (88 ٪ و 87 ٪) من الدورات التي لا تقاعد أي uops.
- يبدو أن UOPS قادم من كاشف تيار الحلقة (نظرًا لأن دورات LSD/UOP هي نفسها تقريبًا مثل الفئران/الدورة.
- لقطة شاشة لجدول ذاكرة مخطط وحدة المعالجة المركزية Haswell
- فيما يلي جدول لاختبار عرض النطاق الترددي L3.
- الآن الذاكرة BW و L3 Miss Bytes/Cycle حوالي الصفر.
- SQ أقل توقف (لأننا لا ننتظر الذاكرة).
- بايت/دورات المعاملات L2 أعلى حوالي 2x وحوالي 67 ٪ من الحد الأقصى الممكن 64 بايت/دورة.
- انخفض UOPS_RETIRED_STALLS/CYCLE إلى 66 ٪ من كشك اختبار MEM BW بنسبة 88 ٪.
- تعبئة أكشاك المخزن المؤقت الآن أكثر من 2x أعلى. لا تزال UOPS قادمة من LSD.
- لقطة شاشة من مخطط وحدة المعالجة المركزية Haswell L3 BW Table
- فيما يلي جدول لاختبار عرض النطاق الترددي L2.
- L2 يفتقد Bytes/Cycle أقل بكثير من اختبار L3.
- أصبح uops_retired ٪ المتوقفة الآن حوالي نصف اختبار L3 بنسبة 34 ٪ وأكشاك FB حوالي 17 ٪ أيضًا.
- لا تزال uops قادمة من LSD.
- لقطة شاشة من مخطط وحدة المعالجة المركزية Haswell L2 BW Table
- يوجد أدناه جدول لاختبار الدوران (لا توجد أحمال ، فقط يضيف في حلقة).
- الآن هناك فقط حوالي صفر أكشاك النظام الفرعي للذاكرة.
- تأتي UOPS من المخزن المؤقت لتيار Decode (DSB).
- RATIRED_UOPS/CYCLE عند 3.31 دورات/UOP بالقرب من الحد الأقصى الممكن 4.0 UOPS/CYCLE.
- الفئران تقاعد _uops ٪ متوقفة منخفض جدا في ٪ 8.
- لقطة شاشة لجدول تدور مخطط وحدة المعالجة المركزية Haswell
حاليًا ، لا أملك سوى أفلام CPU_Diagram لـ Haswell و ARM A53 (نظرًا لأنه ليس لدي أنظمة أخرى لاختبارها) ولكن لا ينبغي أن يكون من الصعب إضافة مخططات كتلة أخرى. لا تزال تحصل على جميع المخططات ولكن ليس وحدة المعالجة المركزية.
فيما يلي أحد مخططات Oppat. يوضح مخطط "CPU_BUSY" ما يجري على كل وحدة المعالجة المركزية والأحداث التي تحدث في كل وحدة المعالجة المركزية. على سبيل المثال ، تعرض الدائرة الخضراء خيطًا تدور. تم تصميم هذا الرسم البياني بعد مخطط Kernelshark الخاص بـ Trace-CMD. مزيد من المعلومات حول مخطط CPU_BUSY موجود في قسم أنواع المخططات. يعرض مربع وسيلة الشرح بيانات الحدث (بما في ذلك CallStack (إن وجدت)) للحدث تحت المؤشر. لسوء الحظ ، لا تلتقط لقطة شاشة Windows المؤشر. 
فيما يلي بعض ملفات HTML. معظم الملفات هي لفاصل أقصر ~ 2 ولكن بعضها "ممتلئ" 8 أشواط ثانية. لن يتم تحميل الملفات مباشرة من الريبو ولكنها سيتم تحميلها من صفحة ويب المشروع: https://patinnc.github.io
- Intel Haswell مع رقاقة CPU 4-CPU رقاقة ، Linux OS ، ملف HTML مع أحداث 50+ HW عبر أخذ العينات perf أو
- شريحة Intel 4-CPU أو Windows OS أو ملف HTML مع أحداث 1 HW عبر أخذ العينات Xperf أو
- شريحة Intel 4-CPU 4-CPU كاملة ~ 8 ثوانٍ ، ملف HTML مع أخذ عينات من PCM و XPERF أو
- رقاقة Intel 4-CPU ، Linux OS ، ملف HTML مع 10 أحداث HW في مجموعتين مضاعفين.
- ARM (Broadcom A53) Chip ، Raspberry PI3 Linux HTML ملف مع 14 حدث HW (لمؤشر أسعار المستهلك ، L2 MOESES ، MEM BW إلخ في 2 مجموعات مضاعفة).
- 11 ميجا بايت ، النسخة الكاملة من AULD ARM (BRODCOM A53) ، ملف Raspberry PI3 Linux HTML مع 14 أحداث HW (لمؤشر أسعار المستهلك ، L2 MOESES ، MEM BW إلخ في مجموعتين متعدد الإرسال).
بعض الملفات المذكورة أعلاه هي ~ 2 فترات ثانية مستخرجة من ~ 8 ثانية المدى الطويل. هنا هو المدى الكامل 8:
- ملف Linux Complet Complet HTML Complet HTML هنا للحصول على ملف أكثر اكتمالا. يقوم الملف بإلغاء ضغط Zlib JavaScript لبيانات المخطط ، لذا سترى رسائل تطلب منك الانتظار (حوالي 20 ثانية) أثناء إلغاء الضغط.
بيانات الأوبات المدعومة
- ملفات أداء Linux Perf و/أو Trace-CMD (الملفات الثنائية والنصية) ،
- تم قبول الإخراج Perf Stat أيضًا
- بيانات Intel PCM ،
- بيانات أخرى (مستوردة باستخدام البرامج النصية LUA) ،
- لذلك يجب أن يعمل هذا مع بيانات من Linux العادية أو Android
- حاليًا للحصول على بيانات Perf و Trace-CMD ، تتطلب OPPAT كلا من الملفات النصية الثنائية وما بعد المعالجة ، وهناك بعض القيود على سطر الأوامر "السجل" وخط الأوامر "Perf Script/Trace-CMD".
- يمكن إجراء OppAT لاستخدام ملفات نص النص Perf/Trace-CMD ولكن حاليًا مطلوبة على كل من الملفات الثنائية والنصوص
- بيانات Windows ETW (التي تم جمعها بواسطة Xperf وملقها على نص) أو بيانات Intel PCM ،
- الطاقة التعسفية أو بيانات الأداء المدعومة باستخدام البرامج النصية LUA (لذلك لا تحتاج إلى إعادة ترجمة رمز C ++ لاستيراد البيانات الأخرى (ما لم يصبح أداء LUA مشكلة)))
- اقرأ ملفات البيانات الموجودة على Linux أو Windows بغض النظر عن المكان الذي نشأت فيه الملفات (لذلك اقرأ ملفات Perf/Trace-CMD على ملفات Windows أو ETW على Linux)
تصور الأوبات
فيما يلي بعض ملفات HTML ذات العينات الكاملة: نموذج HTML Sample أو ملف HTML لعينة Linux. إذا كنت على موقع Repo (وليس موقع GitHub.io Project) ، فسيتعين عليك تنزيل الملف ثم تحميله في متصفحك. هذه ملفات ويب قائمة بذاتها تم إنشاؤها بواسطة OPPAT والتي يمكن ، على سبيل المثال ، إرسالها بالبريد الإلكتروني إلى الآخرين أو (كما هو الحال هنا) على خادم ويب.
يعمل Oppat Viz بشكل أفضل في Chrome من Firefox في المقام الأول لأن التكبير باستخدام تمرير الإصبع اللمسات 2 يعمل بشكل أفضل على Chrome.
OPPAT لديه 3 أوضاع التصور:
- آلية المخطط المعتادة (حيث تقرأ OppAt Backend ملفات البيانات وترسل البيانات إلى المتصفح)
- يمكنك أيضًا إنشاء صفحة ويب قائمة بذاتها والتي تعادل "آلية الرسم البياني العادية" ولكن يمكن تبادلها مع مستخدمين آخرين ... تحتوي صفحة الويب المستقلة على جميع البرامج النصية والبيانات المدمجة حتى يمكن إرسالها عبر البريد الإلكتروني إلى شخص ما ويمكنهم تحميلها في متصفحهم. راجع ملفات html في sample_html_files المشار إليها أعلاه و (للحصول على إصدار أطول من lnx_mem_bw4) انظر ملف sample_html_files/lnx_mem_bw4_ful.html المضغوط
- يمكنك "-تحديد" ملف JSON البيانات ثم-تحميل الملف لاحقًا. يحتوي ملف JSON المحفوظ على البيانات التي يحتاج OPPAT إلى إرسالها إلى المتصفح. هذا يتجنب إعادة قراءة ملفات الإدخال perf/xperf ولكنه لن يلتقط أي تغييرات تم إجراؤها في charts.json. يعد ملف HTML الكامل الذي تم إنشاؤه باستخدام خيار -Web_File أكبر قليلاً من ملف - -save. يتطلب-Save/-وضع التحميل بناء oppat. راجع عينة الملفات "المحفوظة" في Sample_data_json_files subdir.
بمعنى المعلومات العامة
- قم برسم جميع البيانات في المتصفح (على Linux أو Windows)
- يتم تعريف المخططات في ملف JSON حتى تتمكن من إضافة الأحداث والمخططات دون إعادة تجميع OppAt
- تشبه واجهة المتصفح نوعًا من Windows WPA (Navbar على اليسار).
- يوضح أدناه NAVBAR الأيسر (القائمة المنزلق الجانب الأيسر).
- يتم تجميع المخططات حسب الفئة (GPU ، وحدة المعالجة المركزية ، الطاقة ، إلخ)
- يتم تعريف الفئات وتعيينها في input_files/charts.json
- يمكن إخفاء المخططات جميعها أو عرضها بشكل انتقائي من خلال النقر على الرسم البياني في Navbar.
- تحوم فوق عنوان الرسم البياني في مخطوطات قائمة NAV اليسرى التي تخطط في العرض
- يمكن رسم بيانات من مجموعة واحدة من الملفات جنبًا إلى جنب مع مجموعة مختلفة
- لذلك يمكنك القول ، قارن أداء Linux Perfe مقابل تشغيل Windows ETW
- أدناه الرسم البياني عرض Linux vs Windows استخدام الطاقة:
- لا يمكنني سوى الوصول إلى طاقة البطارية على كل من Linux و Windows.
- العديد من المواقع لديها بيانات طاقة أفضل بكثير (الفولتية/التيارات/الطاقة بمعدل MSEC (أو أفضل)). سيكون من السهل دمج هذه الأنواع من بيانات الطاقة (مثل من Kratos أو Qualcomm MDPs) ولكن لا يمكنني الوصول إلى البيانات.
- أو قارن بين 2 أشواط مختلفة على نفس النظام الأساسي
- تسبق علامة مجموعة الملفات (file_tag) مسبوقة على العنوان لتمييز المخططات
- يتم تعريف "العلامة" في ملف dire dir's file_list.json و/أو input_files/input_data_files.json
- إن input_files/input_data_files.json عبارة عن قائمة بجميع dives بيانات OPPAT (ولكن يتعين على المستخدم الحفاظ عليها).
- يتم رسم المخططات ذات العنوان نفسه واحدًا تلو الآخر للسماح بالمقارنة السهلة
ميزات الرسم البياني:
يوضح التحوم فوق قسم من خط المخطط نقطة البيانات لهذا السطر في تلك المرحلة
- هذا لا يعمل مع الخطوط العمودية لأنها تربط نقطتين فقط ... فقط يتم البحث في الأجزاء الأفقية من كل سطر عن قيمة البيانات
- فيما يلي لقطة شاشة للحوم على الحدث. يوضح هذا الوقت النسبي لحدث (Cswtich) ، وبعض المعلومات مثل Process/PID/Tid ورقم السطر في الملف النصي حتى تتمكن من الحصول على مزيد من المعلومات.
- فيما يلي لقطة شاشة تعرض معلومات callstack (إن وجدت) للأحداث.
التكبير
- التكبير غير المحدود إلى مستوى النانوسيك والتكبير.
- من المحتمل أن تكون هناك أوامر ذات نقاط أكبر من النقاط من البكسل ، لذا يتم عرض المزيد من البيانات أثناء تكبيرك.
- فيما يلي لقطة شاشة توضح التكبير إلى مستوى microsecond. يوضح هذا CallStack لحدث Sched_switch حيث يتم حظر Spin.x عن طريق إجراء عملية تعيين الذاكرة والانتقال إلى الخمول. يعرض "CPU" المشغول "المخطط" الخمول "فارغًا.
.
- يمكن تكبير المخططات بشكل فردي أو يمكن ربط الرسوم البيانية بنفس file_tag بحيث يغير التصغير/تحديد المخطط 1 الفاصل الزمني لجميع المخططات مع نفس file_tag
- قم بالتمرير إلى أسفل شريط Navbar الأيسر وانقر على "Zoom/Pan: Unlinting". سيؤدي هذا إلى تغيير عنصر القائمة إلى "Zoom/Pan: Linked". سيؤدي ذلك إلى تكبير/عموم جميع المخططات في مجموعة ملفات إلى أحدث وقت Zoom/Pan المطلق. سيستغرق هذا بعض الوقت لإعادة رسم جميع المخططات.
- في البداية يتم رسم كل مخطط يعرض جميع البيانات المتاحة. إذا كانت المخططات الخاصة بك من مصادر مختلفة ، فمن المحتمل أن يكون T_Begin و T_END (للمخططات من مصادر مختلفة) مختلفة.
- بمجرد الانتهاء من عملية التكبير/المقلاة ، يكون الارتباط ساري المفعول ، ثم ستقوم جميع المخططات في مجموعة الملفات بتكبير/عموم إلى نفس الفاصل الزمني المطلق.
- هذا هو السبب في أن "الساعة" المستخدمة لكل مصدر يجب أن تكون هي نفسها.
- يمكن أن تترجم OPPAT من ساعة إلى أخرى (مثل GetTime (clock_monotonic) و getTimeOfDay ()) ولكن هذا المنطق
- يتم دائمًا تكبير أي FlameGraphs للفاصل الزمني إلى فاصل "امتلاك المخططات" بغض النظر عن حالة الارتباط.
- يمكنك التكبير/الخروج بواسطة:
- تكبير في: عجلة الماوس رأسياً على منطقة الرسم البياني. يتكبير المخطط في الوقت الذي في وسط الرسم البياني.
- على جهاز الكمبيوتر المحمول الخاص بي ، يقوم هذا بالتمرير 2 أصابعًا رأسيًا على لوحة اللمس
- تكبير: النقر على الرسم البياني وسحب الماوس إلى اليمين وإطلاق الماوس (سيتم تكبير الرسم البياني إلى الفاصل الزمني المحدد)
- التصغير: النقر على الرسم البياني وسحب الماوس إلى اليسار وإطلاق الماوس سيؤدي إلى تكبير نوعًا ما يتناسب عكسيا مع مقدار المخطط الذي حددته. هذا هو ، إذا تركت سحب منطقة الرسم البياني بأكملها تقريبًا ، فسيقوم الرسم البياني بتكبير ~ 2x. إذا تركت للتو اسحب فاصلًا صغيرًا ، فسيقوم الرسم البياني بتصغير الطريق بالكامل.
- التصغير: على جهاز الكمبيوتر المحمول الخاص بي ، قم بعمل تمرير رأسي في لوحة اللمس 2 في الاتجاه المعاكس للتكبير
- عليك أن تكون حذراً حيث يكون المؤشر ... قد تكبر عن غير قصد مخططًا عندما تقصد تمرير قائمة المخططات. لذلك عادةً ما أضع المؤشر على الحافة اليسرى للشاشة عندما أرغب في تمرير الرسوم البيانية.
بنية
- على جهاز الكمبيوتر المحمول الخاص بي ، يقوم هذا بإصبعين على حركة التمرير الأفقية على لوحة اللمس
- باستخدام المربع الأخضر على الصورة المصغرة أسفل الرسم البياني
- يعمل Panning على أي مستوى التكبير
- يتم وضع صورة "Thumbnail" للمخطط الكامل أسفل كل مخطط مع مؤشر للانزلاق على طول الصورة المصغرة حتى تتمكن
- يوضح أدناه وضع مخطط "وحدة المعالجة المركزية مشغول" إلى T = 1.8-2.37 ثانية. يتم وضع الوقت النسبي ووقت البدء المطلق في البيضاوي الأحمر الأيسر. يتم تسليط الضوء على وقت الانتهاء في الجانب الأحمر الأيمن. يظهر الموضع النسبي على الصورة المصغرة بواسطة البيضاوي الأحمر الأوسط.
.
تحوم على إدخال أسطورة الرسم البياني يسلط الضوء على هذا الخط.
- فيما يلي لقطة شاشة حيث يتم تسليط الضوء على طاقة "PKG" (الحزمة)
النقر على إدخال أسطورة الرسم البياني يلبس رؤية هذا الخط.
إن النقر المزدوج على إدخال الأسطورة يجعل هذا الإدخال مرئيًا/مخفيًا فقط
- فيما يلي لقطة شاشة حيث تم النقر المزدوج على قوة "PKG" ، بحيث يكون خط PKG فقط مرئيًا.
- يوضح أعلاه أن المحور ص يتم ضبطه إلى min/max من المتغير (المتغيرات) المعروضة. خطوط "غير معروضة" هي رمادية في الأسطورة. إذا قمت بحوم خط "غير مُظهر" في الأسطورة ، فسيتم رسمه (بينما تحوم على عنصر الأسطورة). يمكنك الحصول على جميع العناصر التي يجب عرضها مرة أخرى عن طريق النقر المزدوج على إدخال أسطورة "غير متكافئ". سيُظهر هذا جميع خطوط "غير معروضة" ، ولكنه سيقوم بتبديل الخط الذي نقرت عليه للتو ... لذا انقر فوق العنصر الذي تم النقر عليه مزدوجًا. أعلم أن هذا يبدو مربكًا.
إذا تم إخفاء إدخال الأسطورة وتم تحومه فوقه ، فسيتم عرضه حتى تحوم
أنواع المخططات:
جمع البيانات لـ OPPAT
يعد جمع بيانات الأداء والطاقة "ظرفية" للغاية. سيرغب شخص في تشغيل البرامج النصية ، وسيريد شخص آخر بدء قياسات مع زر ، ثم بدء مقطع فيديو ثم إنهاء المجموعة مع الضغط على زر. لديّ برنامج نصي لنظام التشغيل Windows ونص نصي لـ Linux يوضح:
- بدء جمع البيانات ،
- تشغيل عبء العمل ،
- إيقاف جمع البيانات
- بعد العملية البيانات (إنشاء ملف نصي من البيانات الثنائية perf/xperf/trace-cmd)
- وضع جميع ملفات البيانات في DIR الإخراج
- إنشاء ملف file_list.json في DIR الإخراج (الذي يخبر OPPAT اسم ونوع ملفات الإخراج)
خطوات جمع البيانات باستخدام البرامج النصية:
- Build Spin.exe (Spin.x) و Wait.exe (wait.x)
- من Oppat Root Dir Do:
- على Linux:
./mk_spin.sh - على Windows :
.mk_spin.bat (من مربع Visual Studio CMD) - سيتم وضع الثنائيات في ./bin subdir
- ابدأ بتشغيل البرامج النصية المقدمة:
- run_perf_x86_haswell.sh - لجمع بيانات Haswell CPU_Diagram
- على Linux ، اكتب:
sudo bash ./scripts/run_perf.sh - بشكل افتراضي ، يضع البرنامج النصي البيانات في dir ../oppat_data/lnx/mem_bw7
- run_perf.sh - يجب أن تكون قد تم تثبيت Trace -CMD وتثبيت Perf
- على Linux ، اكتب:
sudo bash ./scripts/run_perf.sh - بشكل افتراضي ، يضع البرنامج النصي البيانات في dir ../oppat_data/lnx/mem_bw4
- RUN_XPERF.BAT - تحتاج إلى تثبيت xperf.exe.
- على Windows ، من مربع CMD مع امتيازات المسؤول ، اكتب :
.scriptsrun_xperf.sh - بشكل افتراضي ، يضع البرنامج النصي البيانات في dir .. oppat_data win mem_bw4
- قم بتحرير البرنامج النصي Run إذا كنت تريد تغيير الإعدادات الافتراضية
- بالإضافة إلى ملفات البيانات ، يقوم البرنامج النصي Run بإنشاء ملف file_list.json في dir output. يستخدم OPPAT ملف file_list.json لمعرفة أسماء الملفات ونوع الملفات في DIR الإخراج.
- "عبء العمل" للبرنامج النصي Run هو spin.x (أو spin.exe) الذي يقوم باختبار عرض النطاق الترددي للذاكرة على 1 وحدة المعالجة المركزية لمدة 4 ثوان ثم على جميع وحدات المعالجة المركزية لمدة 4 ثوان أخرى.
- برنامج آخر wait.x/wait.exe بدأ أيضا في الخلفية. Wait.cpp يقرأ معلومات البطارية لجهاز الكمبيوتر المحمول الخاص بي. إنه يعمل على جهاز الكمبيوتر المحمول Dual Boot Windows 10/Linux Ubuntu. قد يكون لملف SYSFS اسم مختلف على Linux الخاص بك وبالتأكيد يختلف على Android.
- على Linux ، ربما يمكنك فقط إنشاء ملف prf_trace.data و prf_trace.txt باستخدام نفس بناء الجملة كما هو الحال في Run_perf.sh لكنني لم أحاول ذلك.
- إذا كنت تعمل على جهاز كمبيوتر محمول وترغب في الحصول على طاقة البطارية ، تذكر فصل كابل الطاقة قبل تشغيل البرنامج النصي.
دعم بيانات PCM
- يمكن لـ OPPAT قراءة ملفات PCM .CSV ورسمها.
- فيما يلي لقطة من قائمة المخططات التي تم إنشاؤها.
- لسوء الحظ ، يجب عليك القيام بتصحيح إلى PCM لإنشاء ملف مع طابع زمني مطلق لـ OPPAT لمعالجته.
- وذلك لأن ملف PCM CSV لا يحتوي على طابع زمني يمكنني استخدامه لربط مصادر البيانات الأخرى.
- لقد أضفت التصحيح هنا تصحيح PCM
بناء الأوامر
- على Linux ، اكتب
make in the Oppat Root Dir- إذا كان كل شيء يعمل ، فيجب أن يكون هناك ملف bin/oppat.x
- على Windows ، تحتاج إلى:
- تثبيت إصدار Windows من GNU Make. راجع http://gnuwin32.sourceforge.net/packages/make.htm أو ، فقط للحد الأدنى من الثنائيات المطلوبة ، استخدم http://gnuwin32.sourceforge.net/downlinks/make.php
- ضع هذا "Make" ثنائيًا جديدًا في المسار
- أنت بحاجة إلى برنامج برمجي Visual Studio 2015 أو 2017 C/C ++ (لقد استخدمت كل من VS 2015 Professional و VS 2017 Community Commilers)
- بدء تشغيل مربع مطالبة CMD الأصلي Windows Visual Studio X64
- اكتب
make in the Oppat Root Dir - إذا كان كل شيء يعمل ، فيجب أن يكون هناك ملف bin oppat.exe
- إذا كنت تقوم بتغيير التعليمات البرمجية المصدر ، فربما تحتاج إلى إعادة بناء ملف التبعية
- تحتاج إلى تثبيت Perl
- على Linux ، في OPPAT ROOT DIR DO:
./mk_depends.sh . سيؤدي ذلك إلى إنشاء ملف تبعية يعتمد على _lnx.mk. - on Windows, in the OPPAT root dir do:
.mk_depends.bat . This will create a depends_win.mk dependency file.
- If you are going to run the sample run_perf.sh or run_xperf.bat scripts, then you need to build the spin and wait utilities:
- On Linux:
./mk_spin.sh - On Windows:
.mk_spin.bat
Running OPPAT
- Run the data collection steps above
- now you have data files in a dir (if you ran the default run_* scripts:
- on Windows ..oppat_datawinmem_bw4
- on Linux ../oppat_data/lnx/mem_bw4
- You need to add the created files to the input_filesinput_data_files.json file:
- Starting OPPAT reads all the data files and starts the web server
- on Windows to generate the haswell cpu_diagram (assuming your data dir is ..oppat_datalnxmem_bw7)
binoppat.exe -r ..oppat_datalnxmem_bw7 --cpu_diagram webhaswell_block_diagram.svg > tmp.txt
- on Windows (assuming your data dir is ..oppat_datawinmem_bw4)
binoppat.exe -r ..oppat_datawinmem_bw4 > tmp.txt
- on Linux (assuming your data dir is ../oppat_data/lnx/mem_bw4)
bin/oppat.exe -r ../oppat_data/lnx/mem_bw4 > tmp.txt
bin/oppat.exe -r ../oppat_data/lnx/mem_bw4 --web_file tst2.html > tmp.txt
- Then you can load the file into the browser with the URL address:
file:///C:/some_path/oppat/tst2.html
Derived Events
'Derived events' are new events created from 1 or more events in a data file.
- Say you want to use the ETW Win32k InputDeviceRead events to track when the user is typing or moving the mouse.
- ETW has 2 events:
- Microsoft-Windows-Win32k/InputDeviceRead/win:Start
- Microsoft-Windows-Win32k/InputDeviceRead/win:Stop
- So with the 2 above events we know when the system started reading input and we know when it stopped reading input
- But OPPAT plots just 1 event per chart (usually... the cpu_busy chart is different)
- We need a new event that marks the end of the InputDeviceRead and the duration of the event
- The derived event needs:
- a new event name (in chart.json... see for example the InputDeviceRead event)
- a LUA file and routine in src_lua subdir
- 1 or more 'used events' from which the new event is derived
- the derived events have to be in the same file
- For the InputDeviceRead example, the 2 Win32k InputDeviceRead Start/Stop events above are used.
- The 'used events' are passed to the LUA file/routine (along with the column headers for the 'used events') as the events are encountered in the input trace file
- In the InputDeviceRead lua script:
- the script records the timestamp and process/pid/tid of a 'start' event
- when the script gets a matching 'Stop' event (matching on process/pid/tid), the script computes a duration for the new event and passes it back to OPPAT
- A 'trigger event' is defined in chart.json and if the current event is the 'trigger event' then (after calling the lua script) the new event is emitted with the new data field(s) from the lua script.
- An alternate to the 'trigger event' method is to have the lua script indicate whether or not it is time to write the new event. For instance, the scr_lua/prf_CPI.lua script writes a '1' to a variable named ' EMIT ' to indicate that the new CPI event should be written.
- The new event will have:
- the name (from the chart.json evt_name field)
- The data from the trigger event (except the event name and the new fields (appended)
- I have tested this on ETW data and for perf/trace-cmd data
Using the browser GUI Interface
TBD
Defining events and charts in charts.json
TBD
Rules for input_data_files.json
- The file 'input_files/input_data_files.json' can be used to maintain a big list of all the data directories you have created.
- You can then select the directory by just specifying the file_tag like:
- bin/oppat.x -u lnx_mem_bw4 > tmp.txt # assuming there is a file_tag 'lnx_mem_bw4' in the json file.
- The big json file requires you to copy the part of the data dir's file_list.json into input_data_files.json
- in the file_list.json file you will see lines like:
{ "cur_dir" : " %root_dir%/oppat_data/win/mem_bw4 " },
{ "cur_tag" : " win_mem_bw4 " },
{ "txt_file" : " etw_trace.txt " , "tag" : " %cur_tag% " , "type" : " ETW " },
{ "txt_file" : " etw_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " }- don't copy the lines like below from the file_list.json file:
- paste the copied lines into input_data_files.json. Pay attention to where you paste the lines. If you are pasting the lines at the top of input_data_files.json (after the
{"root_dir":"/data/ppat/"}, then you need add a ',' after the last pasted line or else JSON will complain. - for Windows data files add an entry like below to the input_filesinput_data_files.json file:
- yes, use forward slashes:
{ "root_dir" : " /data/ppat/ " },
{ "cur_dir" : " %root_dir%/oppat_data/win/mem_bw4 " },
{ "cur_tag" : " win_mem_bw4 " },
{ "txt_file" : " etw_trace.txt " , "tag" : " %cur_tag% " , "type" : " ETW " },
{ "txt_file" : " etw_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " }- for Linux data files add an entry like below to the input_filesinput_data_files.json file:
{ "root_dir" : " /data/ppat/ " },
{ "cur_dir" : " %root_dir%/oppat_data/lnx/mem_bw4 " },
{ "cur_tag" : " lnx_mem_bw4 " },
{ "bin_file" : " prf_energy.txt " , "txt_file" : " prf_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " },
{ "bin_file" : " prf_trace.data " , "txt_file" : " prf_trace.txt " , "tag" : " %cur_tag% " , "type" : " PERF " },
{ "bin_file" : " tc_trace.dat " , "txt_file" : " tc_trace.txt " , "tag" : " %cur_tag% " , "type" : " TRACE_CMD " },- Unfortunately you have to pay attention to proper JSON syntax (such as trailing ','s)
- Here is an explanation of the fields:
- The 'root_dir' field only needs to entered once in the json file.
- It can be overridden on the oppat cmd line line with the
-r root_dir_path option - If you use the
-r root_dir_path option it is as if you had set "root_dir":"root_dir_path" in the json file - the 'root_dir' field has to be on a line by itself.
- The cur_dir field applies to all the files after the cur_dir line (until the next cur_dir line)
- the '%root_dir% string in the cur_dir field is replaced with the current value of 'root_dir'.
- the 'cur_dir' field has to be on a line by itself.
- the 'cur_tag' field is a text string used to group the files together. The cur_tag field will be used to replace the 'tag' field on each subsequent line.
- the 'cur_tag' field has to be on a line by itself.
- For now there are four types of data files indicated by the 'type' field:
- type:PERF These are Linux perf files. OPPAT currently requires both the binary data file (the bin_file field) created by the
perf record cmd and the perf script text file (the txt_file field). - type:TRACE_CMD These are Linux trace-cmd files. OPPAT currently requires both the binary dat file (the bin_file field) created by the
trace-cmd record cmd and the trace-cmd report text file (the txt_file field). - type:ETW These are Windows ETW xperf data files. OPPAT currently requires only the text file (I can't read the binary file). The txt_file is created with
xperf ... -a dumper command. - type:LUA These files are all text files which will be read by the src_lua/test_01.lua script and converted to OPPAT data.
- the 'prf_energy.txt' file is
perf stat output with Intel RAPL energy data and memory bandwidth data. - the 'prf_energy2.txt' file is created by the wait utility and contains battery usage data in the 'perf stat' format.
- the 'wait.txt' file is created by the wait utility and shows the timestamp when the wait utility began
- Unfortunately 'perf stat' doesn't report a high resolution timestamp for the 'perf stat' start time
القيود
- The data is not reduced on the back-end so every event is sent to the browser... this can be a ton of data and overwhelm the browsers memory
- I probably should have some data reduction logic but I wanted to get feedback first
- You can clip the files to a time range:
oppat.exe -b abs_beg_time -e abs_beg_time to reduce the amout of data- This is a sort of crude mechanism right now. I just check the timestamp of the sample and discard it if the timestamp is outside the interval. If the sample has a duration it might actually have data for the selected interval...
- There are many cases where you want to see each event as opposed to averages of events.
- On my laptop (with 4 CPUs), running for 10 seconds of data collection runs fine.
- Servers with lots of CPUs or running for a long time will probably blow up OPPAT currently.
- The stacked chart can cause lots of data to be sent due to how it each event on one line is now stacked on every other line.
- Limited mechanism for a chart that needs more than 1 event on a chart...
- say for computing CPI (cycles per instruction).
- Or where you have one event that marks the 'start' of some action and another event that marks the 'end' of the action
- There is a 'derived events' logic that lets you create a new event from 1 or more other events
- See the derived event section
- The user has to supply or install the data collection software:
- on Windows xperf
- See https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install
- You don't need to install the whole ADK... the 'select the parts you want to install' will let you select just the performance tools
- on Linux perf and/or trace-cmd
sudo apt-get install linux-tools-common linux-tools-generic linux-tools- ` uname -r `
- For trace-cmd, see https://github.com/rostedt/trace-cmd
- You can do (AFAIK) everything in 'perf' as you can in 'trace-cmd' but I have found trace-cmd has little overhead... perhaps because trace-cmd only supports tracepoints whereas perf supports tracepoints, sampling, callstacks and more.
- Currently for perf and trace-cmd data, you have to give OPPAT both the binary data file and the post-processed text file.
- Having some of the data come from the binary file speeds things up and is more reliable.
- But I don't want to the symbol handling and I can't really do the post-processing of the binary data. Near as I can tell you have to be part of the kernel to do the post processing.
- OPPAT requires certain clocks and a certain syntax of 'convert to text' for perf and trace-cmd data.
- OPPAT requires clock_monotonic so that different file timestamps can be correlated.
- When converting the binary data to text (trace-cmd report or 'perf script') OPPAT needs the timestamp to be in nanoseconds.
- see scriptsrun_xperf.bat and scriptsrun_perf.sh for the required syntax
- given that there might be so many files to read (for example, run_perf.sh generates 7 input files), it is kind of a pain to add these files to the json file input_filesinput_data_files.json.
- the run_xperf.bat and run_perf.sh generate a file_list.json in the output directory.
- perf has so, so many options... I'm sure it is easy to generate some data which will break OPPAT
- The most obvious way to break OPPAT is to generate too much data (causing browser to run out of memory). I'll probably handle this case better later but for this release (v0.1.0), I just try to not generate too much data.
- For perf I've tested:
- sampling hardware events (like cycles, instructions, ref-cycles) and callstacks for same
- software events (cpu-clock) and callstacks for same
- tracepoints (sched_switch and a bunch of others) with/without callstacks
- Zooming Using touchpad scroll on Firefox seems to not work as well it works on Chrome
.
.
