मल्टी-कोर इंटेल कोर 2 प्रोसेसर (भाग 3) के उदाहरण का उपयोग करके स्केलेबिलिटी समस्याओं को खोजें और हल करें

लेख की निरंतरता: भाग 1 , भाग 2 , भाग 4

कुल कैश आकार

साझा कैश में भीड़भाड़ के कारण स्केलेबिलिटी में कमी का मतलब है कि कैश को बड़ी संख्या में डाउनलोड करने और बाद में कैश लाइन पुनः लोड करने के परिणामस्वरूप। इंटेल कोर 2 प्रोसेसर में, अंतिम स्तर कैश लाइन (एलएलसी) पर एक चूक को L2_LINES_IN.SELF.ANY घटना माना जाता है। यह ईवेंट डाउनलोड, डाउनलोड, निर्देश लाने, और हार्डवेयर और सॉफ़्टवेयर प्रीफ़ैचिंग के दौरान LLC को याद करता है। चर्चा किए गए दो परिदृश्यों के लिए संकेत भिन्न हैं, लेकिन अंतर काफी स्पष्ट है। यदि काम की मात्रा तय हो गई है, तो गैर-अतिव्यापी समानांतर निष्पादन के साथ, एलएलसी की कुल संख्या में चूक से शामिल कोर की संख्या में वृद्धि नहीं होगी। यदि मात्रा नाभिक की संख्या में वृद्धि के साथ बढ़ती है, तो प्रति कोर मिसाइलों की संख्या अपरिवर्तित रहती है। किसी भी मामले में, यह केवल कुल है, और एक मीट्रिक नहीं, कारण की प्रकृति का संकेत देता है।



कई कारण हैं कि ये संख्याएं उपरोक्त नियमों का पालन क्यों नहीं करेंगी। उदाहरण के लिए:

1. सच्ची और झूठी कैश लाइन साझा करने के कारण यातायात में वृद्धि हुई
2. कार्यशील डेटासेट को एलएलसी के आकार में विभाजित करने से कई कोर पर चलने पर दक्षता कम हो जाती है, अर्थात समानांतर प्रक्रियाएं एक दूसरे की रेखाओं को बाहर निकालती हैं।

पहला मामला EXT_SNOOPS.ALL_AGENTS.HITM का उपयोग करके आसानी से कैश लाइनों के उपयोग (वास्तविक या गलत) के रूप में पहचाना जाता है। यह ईवेंट गिना जाता है कि एलएलसी के दौरान कितनी बार अनुरोधित लाइन एक अलग कैश और एक परिवर्तित स्थिति में समाप्त हो जाती है। हम इस लेख के अंतिम खंड में इस स्थिति पर विचार करेंगे।



दूसरा कारण इस खंड में मुख्य एक है। एक विशिष्ट उदाहरण एक एप्लिकेशन है जो बड़े मेट्रिसेस को गुणा करता है, जबकि एलएलसी वॉल्यूम का उपयोग करके डेटा को आधे से अधिक (पूरी तरह से) ब्लॉक में विभाजित किया जाता है। समानांतरकरण इस तथ्य को जन्म दे सकता है कि हालांकि डेटा के अपघटन के कारण प्रत्येक थ्रेड या प्रक्रिया द्वारा हल किए गए मेट्रिसेस का आकार छोटा हो जाएगा, लेकिन अगर अवरुद्ध नहीं बदला गया है, तो दो सॉल्वर को एलएलसी में अपने डेटा के लिए दो बार अधिक मात्रा की आवश्यकता होगी, जो पूरे से अधिक हो सकती है इसकी भौतिक मात्रा। यह कैश के "फिसल" के परिणामस्वरूप होगा जब दो ऐसे धागे या प्रक्रियाएं कैश में अंतरिक्ष के लिए प्रतिस्पर्धा करती हैं, एक दूसरे की कैश लाइनों को भीड़ देती हैं। इसके परिणामस्वरूप, पूरे प्रोग्राम में कैश लाइन डाउनलोड्स (L2_LINES_IN.SELF.ANY) की कुल संख्या जो हिटम से जुड़ी नहीं है (कैश की लाइन में "परिवर्तित" स्थिति में लाइन हिट) काफी बढ़ जाती है।



सही स्केलिंग से कितना प्रदर्शन गिरावट का आकलन करने के लिए एक अन्य तकनीक कैश में अत्यधिक प्रतिस्थापन पर निर्भर करती है, जो कि बड़ी और छोटी संख्या में नोड्स के मामलों में एप्लिकेशन डेटा के कार्यशील सेट के आकार को मापने के लिए है। ऐसा करने के लिए, आप पिन उपयोगिता का उपयोग कर सकते हैं, जो दो स्टार्ट के दौरान कैश स्टैक साइज (CSD) को मापता है। यह तकनीक कैश लाइनों का एक स्टैक बनाती है, जो प्रत्येक नई कैश लाइन को शीर्ष तक पहुंचाती है और स्टैक की गिनती करती है जब तक कि पिछली वस्तु नहीं मिलती है और हटा दी जाती है। प्राप्त स्टैक आकारों का वितरण कार्य अनुप्रयोग डेटा सेट का आकार वितरण है। वितरण में महत्वपूर्ण चोटियों या "कंधों" के सापेक्ष स्थान एलएलसी में प्रत्येक कोर के हिस्से के सापेक्ष दर्शाते हैं कि व्यक्तिगत धागे या प्रक्रियाएं किस हद तक समय से पहले एक-दूसरे की कैश लाइनों को अनलोड करती हैं। इस प्रकार, यदि दो धागे या प्रक्रिया एक साथ एक सामान्य एलएलसी के साथ काम करना चाहिए, तो एक-दूसरे के साथ हस्तक्षेप किए बिना, कार्य डेटा सेट के आकार को एलएलसी कैश के आधे आकार के भीतर फिट करना होगा।



यदि ऐसी पारस्परिक भीड़ होती है, तो ब्लॉक में विभाजित होने वाले डेटा की डिग्री केवल उस स्थिति के लिए प्राप्त की जाती है जब एक थ्रेड या प्रक्रिया में पूरे कैश तक पहुंच होती है। थ्रेड्स / प्रक्रियाओं से आपसी भीड़ की समस्या का समाधान करने के लिए आवश्यक है कि प्राप्त अवरोध भी रनटाइम के पैमाने पर हो, ताकि एकाधिक थ्रेड्स / प्रक्रियाएं सीमित कैश आकार के अपने शेयरों के भीतर सह-अस्तित्व में आ सकें।



बेशक, जब कई कोर और सिस्टम (MPI?) पर लॉन्च करने के इरादे से डेटा को घटाया जाता है, तो यह संभव है कि प्रत्येक कोर को पूरी तरह से कैश में लिखना मुश्किल है, जिससे बस ट्रैफ़िक में बड़ी वृद्धि होती है, इसलिए इसे ध्यान में रखना चाहिए।

डेटा पता अनुवाद बफर का आकार (DTLB)

इंटेल कोर 2 प्रोसेसर के प्रत्येक कोर में एक विशेष 2-स्तरीय DTLB प्रणाली है। इसलिए, हमारे पहले परिदृश्य में, "उचित" डेटा अपघटन के साथ एक एप्लिकेशन को DTLB में आनुपातिक रूप से छोटी संख्या में रिकॉर्ड और दूसरे में एक निरंतर संख्या का उपयोग करना चाहिए। यदि DTLB की संख्या में वृद्धि होती है, तो इसका अर्थ है कि डेटा के अपघटन ने मेमोरी के पृष्ठों तक पहुंच की संख्या में वृद्धि की है, जबकि कार्यशील डेटा सेट का कुल आकार घट गया या समान रहा।



एक बात स्पष्ट है कि इस मामले में पेजिंग डेटा अपघटन में काफी सुधार किया जा सकता है। यह आमतौर पर एक बहु-थ्रेडेड एप्लिकेशन में होता है, जब प्रक्रियाओं में विभाजित होता है, तो प्रत्येक एक वर्चुअल एड्रेस स्पेस में मौजूद होता है जो दूसरों के साथ अंतर नहीं करता है। ऐसी स्थिति बहु-थ्रेडेड अनुप्रयोग में हो सकती है, या साझा मेमोरी का उपयोग करते समय, जब अनुप्रयोग बहुआयामी सरणियों का उपयोग करता है, और डेटा अंतिम आयाम के बजाय प्राथमिक आयाम से विभाजित होता है। MEM_LOAD_RETIRED.DTLB_MISS ईवेंट (केवल डाउनलोड और सटीक गणना मोड), या DTLB_MISSES.ANY (लोड और अनलोड, सटीक मोड नहीं) को गिनकर इस स्थिति का आसानी से पता लगाया जा सकता है।



यदि किसी समस्या का पता लगाया जाता है, तो एक ही घटना के मूल्यों की तुलना करना आवश्यक है जब बड़ी और छोटी संख्या में कोर का उपयोग किया जाता है, तो यह समझने के लिए कि समस्या कहां से उत्पन्न होती है, आपको कोड के उस हिस्से को देखने की जरूरत है जहां अस्थिर व्यवहार खुद को VTune विश्लेषक (मॉड्यूल, हॉट स्पॉट, और फिर जगह में दिखाता है) स्रोत कोड में)। स्रोत कोड को देखने के लिए इस दृष्टिकोण के साथ, समस्या का स्रोत ढूंढना मुश्किल नहीं होना चाहिए।



आप एक और विश्लेषण विधि का उपयोग कर सकते हैं, उदाहरण के लिए, वर्चुअल पतों तक पहुंचने का हिस्टोग्राम बनाएं। यदि पहुंच क्षेत्र सन्निहित और अनुक्रमिक नहीं हैं, तो कई समस्याएं स्पष्ट रूप से छिपी हुई हैं।

कैश लाइनों तक व्यक्तिगत पहुंच

इंटेल कोर 2 प्रोसेसर में, कैश लाइनों द्वारा एक्सेस और डेटा ट्रांसफर किया जाता है, जो 64 आसन्न बाइट्स हैं। साझा मेमोरी के साथ समानांतर निष्पादन में, व्यक्तिगत कैश लाइनों तक पहुंच के लिए प्रतिस्पर्धा संभव है। इसलिए, जब भी एक ही एड्रेस स्पेस में दो थ्रेड्स का संचालन होता है, तो डेटा इन 64-बाइट कैश लाइनों में से किसी एक में पहुंचता है, एक्सेस के लिए प्रतिस्पर्धा हो सकती है, जिसमें एक धागा जो स्ट्रिंग का वर्तमान मालिक नहीं है। अवरुद्ध है। समानांतर प्रक्रियाओं के मामले में यह समस्या संभव नहीं है, क्योंकि उनमें से प्रत्येक का अपना पता स्थान है।



कैश लाइन को साझा करना जरूरी नहीं कि पहुंच के लिए विवाद हो। कैश प्रोटोकॉल (MESI) एक मल्टी-कोर, मल्टी-सॉकेट प्लेटफॉर्म के बीच डेटा साझा करने की अनुमति देता है। केवल-पढ़ने के लिए कैश लाइन साझा की जा सकती है, और कैश प्रोटोकॉल कैश कोर की कई प्रतियों को कई कोर के लिए अनुमति देता है। इस स्थिति में, कैश लाइन की प्रतियां तथाकथित वितरित स्थिति (साझा, एस) में रहेंगी। जैसे ही प्रतियों में से एक को बदल दिया जाता है, कैश लाइन की स्थिति संशोधित (एम) में बदल जाती है। राज्य का यह परिवर्तन अन्य गुठली द्वारा किसी का ध्यान नहीं जाता है, जिसकी प्रतियां एरोनस राज्य (अमान्य, I) में बदल जाती हैं। यदि कैश लॉक उपसर्ग को मेमोरी एक्सेस इंस्ट्रक्शन पर लागू किया जाता है या जब xchg इंस्ट्रक्शन का उपयोग किया जाता है और इसी तरह एक कैश लाइन को एक्सक्लूसिव (E) स्थिति में रखा जा सकता है। इस स्थिति में, कैश लाइन तक अनन्य पहुंच की गारंटी है। यह बहु-थ्रेडेड गतिविधियों को समन्वित करने के लिए उपयोग किए जाने वाले म्यूटेक्स-लॉकिंग सिंक्रनाइज़ेशन विधियों का मूल तंत्र है।



साझा मेमोरी वातावरण में कैश लाइनों के साथ काम करते समय, स्थितियों के दो समूह संभव हैं, प्रत्येक में दो विकल्प। यदि कैश लाइन के भीतर धाराओं की पहुंच ओवरलैप है, तो यह वैध साझाकरण है। यदि कैश लाइन के भीतर की सीमाएं ओवरलैप नहीं होती हैं, तो यह एक गलत साझाकरण है। दूसरा अलग, लेकिन साझा-संबंधित अंतर यह है कि कैश लाइन का उपयोग करते समय लॉक का उपयोग किया जाता है या नहीं।



अनलॉक की गई वितरित कैश लाइनों की प्रतियोगिता में अक्सर अस्थिर रनटाइम, अस्थिर प्रदर्शन इवेंट काउंटर और यहां तक ​​कि परिणाम भी होते हैं। यह इस तथ्य के कारण है कि प्रतिस्पर्धी राज्य का संकल्प प्रतिस्पर्धी कॉलिंग के विशिष्ट विवेक पर निर्भर करता है। यदि रनटाइम अस्थिर है, लेकिन परिणाम स्थिर हैं, तो इसका कारण गैर-अवरुद्ध झूठी साझाकरण है। यदि परिणाम और रनटाइम अस्थिर हैं, तो यह गैर-अवरुद्ध वास्तव में साझा कैश लाइनों तक पहुंच का एक स्पष्ट संकेत है, और अक्सर दौड़ की स्थिति इसका कारण है। इस स्थिति में, इंटेल थ्रेड चेकर का उपयोग दौड़ की स्थिति और संबंधित एक्सेस स्थितियों को खोजने के लिए बेहद उपयोगी है।



अवरुद्ध साझाकरण थ्रेड सिंक्रनाइज़ेशन की नींव है। एक अवरुद्ध चर या कैश लाइन के लिए प्रतिस्पर्धा के कारण अनुक्रमिक पहुंच होती है। यह एक ही समय में किए जाने वाले काम की मात्रा को कम कर देता है, जिससे एप्लिकेशन की खराब मापनीयता बढ़ जाती है।



प्रदर्शन ईवेंट आपको इन विवादित लाइनों के ट्रैफ़िक का मूल्यांकन करने की अनुमति देते हैं। कैश लाइन के लिए प्रतिस्पर्धात्मक पहुंच प्रबंधित डाउनलोड या हार्डवेयर प्रीफ़ैच ब्लॉकों के कारण एलएलसी की संख्या में वृद्धि का कारण बन सकती है। जब कोई डाउनलोड एलएलसी मिस हो जाता है, तो निष्पादन की पूरी मात्रा के लिए रोक दिया जा सकता है कि कैश लाइन को मेमोरी से लोड किया गया है। जब एक चर अनलोड किया जाता है, तो एक विशेष राज्य में कैश लाइनों को डालने के लिए एक विशेष उपयोग अनुरोध (आरएफओ) की आवश्यकता होती है। बस यातायात और अनुप्रयोग स्केलेबिलिटी के लिए परिणाम क्या होंगे, हम पहले ही चर्चा कर चुके हैं। ये पहलू आपस में जुड़े हुए हैं, लेकिन यहाँ हम समस्या को थोड़ा अलग दृष्टिकोण से समझते हैं।



ऐसी घटनाओं की एक श्रृंखला है जो इस तरह की पहुंच समस्याओं का पता लगाने के लिए उपयोगी हैं। नीचे बस सबसे स्पष्ट हैं:

1. EXT_SNOOP.ALL_AGENTS.HITM
2. MEM_LOAD_RETIRED.L2_LINE_MISS
3. MEM_LOAD_RETIRED.L2_MISS
4. BUS_TRANS_BURST.SELF
5. BUS_TRANS_RFO.SELF
6. BUS_HITM_DRV
7. L2_LD.SELF.E_STATE
8. L2_LD.SELF.I_STATE
9. L2_LD.SELF.S_STATE

EXT_SNOOP ईवेंट गिनता है कि एलएलसी मिस बस पर एक और कर्नेल से हिट-संशोधित (हिटम) प्रतिक्रिया का कारण कितनी बार हुआ। BUS_HITM_DRV ईवेंट में एक "रिवर्स" क्रिया है: निर्दिष्ट कर्नेल ने कितनी बार यह प्रतिक्रिया भेजी। MEM_LOAD_RETIRED ईवेंट सटीक गणना मोड में काम करता है, जिससे आपको L2 मिस ​​होने वाले सटीक डाउनलोड का पता चल सके। जबकि कैश लाइन अनुपलब्ध है, यह मिस बस पर केवल एक लेनदेन का कारण होगा। इसलिए, इस घटना का L2_LINE_MISS संस्करण, अनुरोधित कैश लाइनों की संख्या को गिना जाता है, और L2_MISS संस्करण कुल संख्या की यादों को गिनता है। उनके बीच का अंतर निर्दिष्ट लाइन के लिए कॉल की संख्या को दर्शाता है जो पहले मिस के बीच हुई थी जो कैश लाइन अनुरोध का कारण बनी और जिस क्षण लाइन बस पर आ गई।



गैर-अवरुद्ध झूठी साझाकरण का मामला स्थिति को कुछ हद तक जटिल करता है, खासकर अगर आईपी एल 1 डी प्रीफ़ेट यूनिट कैश मिस को एक निश्चित पहुंच पैटर्न के रूप में पहचानता है और स्मृति से पुनर्प्राप्त करने की कोशिश करता है। यह विशेष रूप से छोरों में होने वाली झूठी लाइन साझा करने की स्थिति पर लागू होता है जब वे एक साथ कई थ्रेड्स द्वारा निष्पादित होते हैं। यहां कठिनाई यह है कि सटीक घटना MEM_LOAD_RETIRED.L2_LINE_MISS मिस को नजरअंदाज कर देगा, क्योंकि यह एलएलसी के लिए जिम्मेदार नहीं है, लेकिन आईपी प्रीफैच ब्लॉक में। ये एलएलसी मिसेज L2_LD.SELF.I_STATE ईवेंट में शामिल किए जाएंगे। हालाँकि, यहाँ MEM_LOAD_RETIRED.L2_MISS समस्या को स्थानीय बनाने में मदद करेगा। जब एकल और बहु-थ्रेडेड काउंट के मामले में काउंटरों के मूल्यों की तुलना करते हैं, तो वीट्यून विश्लेषक ग्राफ पर EXT_SNOOP की एक बड़ी संख्या के साथ इस घटना के अचानक फटने से समस्या वाली जगह का पता लगाने की अनुमति मिलेगी।