कैश - फ्लश और अमान्य ऑपरेशन

Question

मेरे पास कैश सिंक्रनाइज़ेशन ऑपरेशंस पर कुछ प्रश्न हैं।

अमान्य: सीपीयू किसी डिवाइस द्वारा अद्यतन स्मृति के एक हिस्से को पढ़ने की कोशिश करने से पहले, इसी स्मृति को अमान्य करने की आवश्यकता है।

फ्लश: इससे पहले कि डिवाइस सीपीयू द्वारा अद्यतन स्मृति के एक हिस्से को पढ़ते हैं, सीपीयू (? वापस लिखें भी सही है) याद करने के लिए कैश से सामग्री, ताकि डिवाइस अद्यतन सामग्री के साथ स्मृति से सामग्री पढ़ता फ्लश चाहिए।

यदि फ्लश नहीं किया जाता है तो यह स्मृति में मौजूद जंक डेटा पढ़ सकता है क्योंकि स्मृति अभी भी कैश में लिखी गई सामग्री के साथ अद्यतन नहीं है।

कृपया पुष्टि करें कि मेरी उपरोक्त समझ सही है या नहीं?

आप दोनों फ्लश और अमान्य कैसे जोड़ना चाहते हैं? मैंने सुना है कि डिवाइस नियंत्रण वर्णनकर्ताओं के साथ खेलते समय हमें फ्लश और अमान्य करने के द्वारा सिंक्रनाइज़ करने की आवश्यकता है। ऐसा क्यों?

क्या हमें फ्लश की तरह अनुक्रम का पालन करने की आवश्यकता है जिसके बाद अवैध है?

क्या कोई परिदृश्य है जिसमें फ्लश के बाद अमान्यता उपयोगी होगी?

Answer 1

फ्लश कैश की सामग्री को मुख्य मेमोरी में वापस लिखता है, और अवैध कैश लाइनों को अवैध के रूप में अमान्य करता है ताकि भविष्य में मुख्य स्मृति पर पढ़ा जा सके।

मुझे लगता है कि यदि आप मेमोरी के ब्लॉक को अपडेट कर रहे थे तो फ्लश और अमान्य हो जाएगा: फ्लश यह सुनिश्चित करेगा कि डिवाइस की नवीनतम सामग्री होगी, और अमान्य तब यह सुनिश्चित करेगा कि जब डिवाइस समाप्त हो जाए तो CPU स्मृति से नई सामग्री पढ़ें।

Answer 2

कृपया पुष्टि करें कि मेरी उपरोक्त समझ सही है या नहीं?

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

जब आप दोनों फ्लश गठबंधन और रद्द करने के लिए करना चाहते हैं? मैंने सुना है कि डिवाइस नियंत्रण डिस्क्रिप्टर के साथ खेलते समय हमें फ्लश और अमान्य करने के द्वारा सिंक्रनाइज़ करने की आवश्यकता है। ऐसा क्यों?

के बाद से डीएमए एक टैग में बताया गया है कुछ परिदृश्यों (यह मानते हुए कि HW बफर गैर संचित करने योग्य डिवाइस स्मृति है) देखते हैं:

1. HW बफर करने के लिए डीडीआर स्मृति से डीएमए हस्तांतरण डेटा।
2. डीडब्ल्यू ट्रांसफर डेटा एचडब्ल्यू बफर से डीडीआर (एचडब्लू प्राप्त डेटा और सीपीयू के लिए इसे उपलब्ध करना चाहते हैं)
3. डीडीआर से डीडीआर डीडीआर के दूसरे क्षेत्र में डीएमए हस्तांतरण।

1. डीडीआर बफर डीएमए से पहले प्लावित किया जाना चाहिए। ड्राइवर बफर गैर कैशबल है इसलिए अमान्यता की आवश्यकता नहीं है।
2. डीडीआर बफर पहले या बाद में 0 (NOTE विवरण के लिए नीचे देखें) डीएमए ट्रांसफर करना सीपीयू को कैश से 'पुराने' डेटा का उपयोग करने से रोकने के लिए ट्रांसफर करना चाहिए। एचडब्ल्यू बफर की फ्लशिंग अनावश्यक है।
3. 'स्रोत' बफर फ़्लश किया जाना चाहिए, 'गंतव्य' बफर को अमान्य किया जाना चाहिए। इसलिए ट्रांसफर से पहले डीएमए के लिए वैध डेटा मेमोरी में है, और डीएमए के काम के बाद सीपीयू कैश से 'गंदगी' नहीं लेता है।

NOTE: यह स्पष्ट है कि 'स्रोत' DMAing से पहले प्लावित किया जाना चाहिए है। अभी भी सवाल है कि को अमान्य कर दें। तकनीकी रूप से यह सीपीयू 'गंतव्य' डेटा तक पहुंचने का प्रयास करेगा और डीएमए के पहले या बाद में हो सकता है (हमें यह सुनिश्चित करना चाहिए कि डीएमए ने नौकरी खत्म कर दी हो)। आईआरएल के बाद अमान्य कर रहा है डीएमए की समस्या हो सकती है। आप देख सकते हैं के रूप में इस विशेष मंच के लिए रद्द DMAing से पहले किया जाना चाहिए Flush/Invalidate range by virtual address; ARMv8; Cache;

का संदर्भ लें। एआरएमवी 7 डिवाइस के लिए बीएसपी कोड को भी रैंपिंग करते हुए मुझे को डीएमए ट्रांसफर से पहले गंतव्य बफर को अमान्य करने की सिफारिश मिली।

हम अमान्य के बाद फ्लश की तरह एक दृश्य का पालन करने की जरूरत है?

मानते हैं कि स्रोत और गंतव्य बफर एक-दूसरे को अलग नहीं करते हैं, निर्भरता नहीं है। आप flush-invalidate या invalidate-flush कर सकते थे।

वहाँ एक परिदृश्य जिसमें फ्लश के बाद अमान्य उपयोगी होगा है?

ऐसा मत सोचो।