क्लब और PCOMMIT

क्लब और PCOMMIT


इंटेल मैनुअल के नवीनतम संस्करण में एसएसडी जैसे गैर-वाष्पशील भंडारण के लिए कुछ नए निर्देश हैं। वह किस बारे में है?

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

पहले अंक पर टोडर मोलोव, लुईस आइजनर, अरुप डे, जोएल कोबर्न और स्टीवन स्वानसन का एक अच्छा पेपर है; मैं नीचे उनका एक ग्राफ़ प्रस्तुत करने जा रहा हूँ।

क्लब और PCOMMIT

हर चीज़ “मोनेटा” कहती है क्योंकि यह उनके सिस्टम का नाम है (जो बहुत अच्छा है, बीटीडब्ल्यू; मैं यह देखने के लिए पेपर पढ़ने की सलाह देता हूं कि उन्होंने यह कैसे किया)। उनका “बेसलाइन” मामला आपके स्टॉक सिस्टम से निकलने की तुलना में काफी बेहतर है। उन्होंने कई अनुकूलन किए (उदाहरण के लिए, लिनक्स के आईओ अनुसूचक को दरकिनार करना और जहां संभव हो संदर्भ स्विच को हटाना), जो सादे पुराने लिनक्स पर विलंबता को 62% तक कम कर देता है। इसके बावजूद, लेन-देन की हार्डवेयर + डीएमए लागत (बार का सफेद भाग) ओवरहेड द्वारा बौनी हो जाती है। ध्यान दें कि वे डीएमए की लागत को हार्डवेयर ओवरहेड का हिस्सा मानते हैं।

वे ओएस को पूरी तरह से बायपास करने और ओवरहेड को कम करने में सक्षम हैं, लेकिन यह अभी भी सच है कि लिखने की अधिकांश लागत ओवरहेड है।

एनवीआरएएम संचालन के लिए ओएस बायपास स्पीडअप

सभी ओवरहेड्स से छुटकारा पाने में सक्षम नहीं होने के बावजूद, उन्हें छोटे माइक्रोबेंचमार्क और वास्तविक कोड दोनों पर काफी महत्वपूर्ण स्पीडअप मिलते हैं। तो यह एक समस्या है. जब आपका I/O डिवाइस वास्तव में तेज़ होता है तो OS I/O पर काफी बड़ा कर लगाता है।

हो सकता है कि आप अपने एनवीआरएएम डिवाइस को मेमोरी के क्षेत्र में मैप करके और आवश्यकतानुसार चीजें करके उस समस्या के बड़े हिस्से को बायपास कर सकें। लेकिन इससे एक और समस्या उत्पन्न हो जाती है। यदि आप ट्रांजेक्शनल सिमेंटिक्स जैसा कुछ चाहते हैं, तो कैश एनवीआरएएम क्षेत्र के साथ कैसे इंटरैक्ट करता है, इसके बीच प्रतिबाधा बेमेल है।

कुमुद भंडारी, ध्रुव आर. चक्रवर्ती और हंस-जे की इस रिपोर्ट में इसका अधिक विस्तार से वर्णन किया गया है। बोहम. मैं उनके कुछ आंकड़े भी उधार लेने जा रहा हूं।

रफ मेमोरी पदानुक्रम आरेख

हमें यह एनवीआरएएम क्षेत्र मिला है जो सुरक्षित और स्थायी है, लेकिन सीपीयू को इसे प्राप्त करने से पहले, इसे अलग-अलग ऑर्डर की गारंटी के साथ कई परतों से गुजरना पड़ता है। वे निम्नलिखित उदाहरण देते हैं:

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

डालने CLFLUSH निर्देश हर जगह काम करते हैं, लेकिन वह कितना ओवरहेड है?

पढ़ने और लिखने पर दृढ़ता

वे जिन चार मेमोरी प्रकारों को देखते हैं (और वे चार जो x86 समर्थित हैं) राइटबैक (डब्ल्यूबी), राइटथ्रू (डब्ल्यूटी), राइट कंबाइन (डब्ल्यूसी), और अनचेचेबल (यूसी) हैं। डब्ल्यूबी वह है जिससे आप सामान्य परिस्थितियों में निपटते हैं। मेमोरी को कैश किया जा सकता है और जब भी इसकी आवश्यकता होती है तो इसे वापस लिखा जाता है। डब्ल्यूटी मेमोरी को कैश करने की अनुमति देता है, लेकिन लिखने को सीधे मेमोरी में लिखना पड़ता है, यानी, मेमोरी को कैश के साथ अद्यतन रखा जाता है। यूसी को कैश नहीं किया जा सकता। WC, UC की तरह है, सिवाय इसके कि लिखने को मेमोरी में भेजे जाने से पहले एकत्रित किया जा सकता है।

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

मुझे ऐसा कभी-कभी करना पड़ा क्योंकि मैं एक चिप कंपनी के लिए काम करता था, और जब हमें पहली बार चिप वापस मिली, तो हमें अक्सर यह नहीं पता था कि बग के आसपास काम करने के लिए हमें किन बिट्स को अक्षम करना होगा। प्रगति करने का सबसे सरल तरीका अक्सर कैश को पूरी तरह से अक्षम करना होता है। वह “काम करता है”, लेकिन DOS जैसे न्यूनतम OS भी WB मेमोरी के बिना बूट करने में काफी धीमे होते हैं। मेरी याददाश्त यह है कि Win 3.1 एक घंटे का बड़ा हिस्सा लेता है, और Win 95 एक कई घंटे की प्रक्रिया है।

_b बेंचमार्क स्मृति में दृश्यमान होने के लिए लिखने को बाध्य करता है। डब्ल्यूबी मामले के लिए, इसमें एक शामिल है MFENCE इसके बाद ए CLFLUSH. दृश्यता बाधाओं के साथ WB अन्य विकल्पों की तुलना में काफी धीमा है। यह डब्ल्यूबी पर परिमाण की कई क्रम की मंदी है जब लिखने के लिए ऑर्डर करने और फ्लश करने की आवश्यकता नहीं होती है।

वे कुछ वास्तविक डेटा संरचनाओं पर बेंचमार्क भी चलाते हैं, इस शर्त के साथ कि डेटा लगातार दिखाई देना चाहिए।

डेटा संरचना संचालन पर दृढ़ता ओवरहेड

नियमित WB मेमोरी का प्रदर्शन बहुत धीमा हो सकता है: कैश के बिना चलने के प्रदर्शन के 2 गुना के भीतर। और यह केवल कैश पदानुक्रम से बाहर निकलने का ओवरहेड है – यह सच है, भले ही आपका लगातार भंडारण असीम रूप से तेज़ हो।

अब, आइए देखें कि इंटेल ने इसे कैसे संबोधित करने का निर्णय लिया। दो नए निर्देश हैं, CLWB और PCOMMIT.

CLWB जैसा कार्य करता है CLFLUSHइसमें यह डेटा को मेमोरी में लिखे जाने के लिए मजबूर करता है। हालाँकि, यह कैश को डेटा फेंकने के लिए बाध्य नहीं करता है, जिससे भविष्य में पढ़ना और लिखना बहुत तेज़ हो जाता है। भी, CLFLUSH के संबंध में ही आदेश दिया गया है MFENCEलेकिन CLWB के संबंध में भी आदेश दिया गया है SFENCE. यहां उनका विवरण दिया गया है CLWB:

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

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

सीएलडब्ल्यूबी अनुदेश केवल स्टोर-फेंसिंग संचालन द्वारा आदेशित किया जाता है। उदाहरण के लिए, सॉफ़्टवेयर यह सुनिश्चित करने के लिए SFENCE, MFENCE, XCHG, या LOCK-उपसर्ग निर्देशों का उपयोग कर सकता है कि पिछले स्टोर राइट-बैक में शामिल हैं। CLWB अनुदेश को किसी अन्य CLWB या CLFLUSHOPT अनुदेश द्वारा आदेशित करने की आवश्यकता नहीं है। सीएलडब्ल्यूबी को तार्किक प्रोसेसर द्वारा उसी पते पर निष्पादित पुराने स्टोरों के साथ अंतर्निहित रूप से ऑर्डर किया गया है।

CLWB के निष्पादन PCOMMIT के निष्पादन के साथ परस्पर क्रिया करते हैं। PCOMMIT निर्देश कुछ स्टोर-टू-मेमोरी ऑपरेशंस पर काम करता है जिन्हें मेमोरी में स्वीकार किया गया है। CLWB को पुराने स्टोर के समान कैश लाइन के लिए निष्पादित किया जाता है, जिसके कारण स्टोर मेमोरी में स्वीकार हो जाता है जब CLWB निष्पादन विश्व स्तर पर दृश्यमान हो जाता है।

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

PCOMMIT निर्देश कुछ स्टोर-टू-मेमोरी ऑपरेशंस को लगातार मेमोरी रेंज को लगातार (पावर विफलता संरक्षित) बनने का कारण बनता है। 1 विशेष रूप से, PCOMMIT उन स्टोर्स पर लागू होता है जिन्हें मेमोरी में स्वीकार किया गया है।

जबकि सभी स्टोर-टू-मेमोरी ऑपरेशन अंततः मेमोरी में स्वीकार किए जाते हैं, निम्नलिखित आइटम उन क्रियाओं को निर्दिष्ट करते हैं जिन्हें सॉफ़्टवेयर यह सुनिश्चित करने के लिए ले सकता है कि वे स्वीकार किए जाते हैं:

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

यदि PCOMMIT को एक स्टोर के बाद एक सतत मेमोरी रेंज को मेमोरी में स्वीकार किए जाने के बाद निष्पादित किया जाता है, तो PCOMMIT विश्व स्तर पर दृश्यमान होने पर स्टोर लगातार बन जाता है। इसका तात्पर्य यह है कि, यदि PCOMMIT का निष्पादन विश्व स्तर पर दिखाई देता है जब एक बाद के स्टोर को लगातार मेमोरी में निष्पादित किया जाता है, तो वह स्टोर उन स्टोर्स से पहले लगातार नहीं बन सकता है जिन पर PCOMMIT लागू होता है।

निम्नलिखित आइटम PCOMMIT और अन्य परिचालनों के बीच ऑर्डर का विवरण देते हैं:

एक तार्किक प्रोसेसर यह सुनिश्चित नहीं करता है कि PCOMMIT का निष्पादन शुरू करने से पहले CLFLUSHOPT और CLWB (उस तार्किक प्रोसेसर द्वारा) के पिछले स्टोर और निष्पादन विश्व स्तर पर दिखाई दे रहे हैं। इसका तात्पर्य यह है कि सॉफ़्टवेयर को PCOMMIT निष्पादित करने से पहले पिछले स्टोर-टू-मेमोरी संचालन और लगातार मेमोरी रेंज के लिए CLFLUSHOPT और CLWB निष्पादन सुनिश्चित करने के लिए उचित बाड़ लगाने के निर्देश (उदाहरण के लिए, SFENCE) का उपयोग करना चाहिए (ताकि वे मेमोरी में स्वीकार किए जाएं)।

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

PCOMMIT के निष्पादन का आदेश SFENCE, MFENCE, XCHG या LOCK-उपसर्ग निर्देशों के निष्पादन और क्रमबद्ध निर्देशों (उदाहरण के लिए, CPUID) के संबंध में दिया जाता है।

लोड संचालन के संबंध में PCOMMIT के निष्पादन का आदेश नहीं दिया गया है। सॉफ़्टवेयर PCOMMIT के साथ लोड ऑर्डर करने के लिए MFENCE का उपयोग कर सकता है।

PCOMMIT का निष्पादन अनुदेश धारा को क्रमबद्ध नहीं करता है।

कितना CLWB और PCOMMIT वास्तव में प्रदर्शन में सुधार उनके कार्यान्वयन पर निर्भर करेगा। इन्हें बेंचमार्क करना और देखना दिलचस्प होगा कि वे कैसा प्रदर्शन करते हैं। किसी भी स्थिति में, यह WB/NVRAM प्रतिबाधा बेमेल समस्या को हल करने का एक प्रयास है। यह सीधे तौर पर ओएस ओवरहेड समस्या का समाधान नहीं करता है, लेकिन काफी हद तक अतिरिक्त हार्डवेयर के बिना इस पर काम किया जा सकता है।

यदि आपको यह पोस्ट पसंद आई है, तो संभवतः आपको ब्रॉडवेल और नए इंटेल सर्वर भागों में कैश विभाजन के बारे में पढ़ने में भी आनंद आएगा.

मैनुअल में इसे पहचानने और इंगित करने के लिए एरिक ब्रॉन को धन्यवाद, और टाइपो को ढूंढने के लिए लिआ हैनसन, नैट रोवे और ‘अनविंड’ को धन्यवाद।

यदि आपके पास पर्याप्त कागजात नहीं हैं, तो ज़्वोनिमिर बैंडिक ने एक प्रकार के एनवीआरएएम से 1.4 यूएस विलंबता और 700k आईओपीएस प्राप्त करने पर डेजन वुसिनिक, क्विंगबो वांग, सिरिल गयोट, रॉबर्ट माटेस्कु, फिलिप ब्लागोजेविक, लुइज़ फ्रैंका-नेटो, डेमियन ले मोल, ट्रेवर बंकर, जियान जू और स्टीवन स्वानसन के एक पेपर की ओर इशारा किया।

यदि आपको यह पोस्ट पसंद आया, तो आपको “नई” सीपीयू सुविधाओं पर यह संबंधित पोस्ट भी पसंद आ सकती है।



Source link

Postagens Similares

  • Co by było, gdyby Twoja strona indeksowa była inteligentna?

    Jedna rzecz, która nie podoba mi się w większości blogów (firmowych i osobistych), to to, że ich strony indeksowe zwykle zawierają nieatrakcyjne listy linków ułożone w odwrotnej kolejności. Zasadniczo nikt nie odwiedza indeksu Twojego bloga z przyzwyczajenia, zwłaszcza jeśli rzadko blogujesz, ponieważ treść nigdy się nie zmienia. Następnie tworzysz biuletyn i obecność na Twitterze, aby…

  • 評論:機器之聲:我在發電廠及其他地方的生活(卡爾·巴托斯)

    機器的聲音:我在發電廠及其他地方的生活 是卡爾·巴托斯 (Karl Bartos) 的自傳,他以 Kraftwerk 的成員和聯合作曲家而聞名。這本書從巴托斯的早年生活開始,記錄了戰後德國的生活。他談到了通過他的妹妹聽到披頭士樂隊和英國節拍音樂的最初靈感。他講述了自己在電信工程學徒期間是如何接觸音樂的,在工作翻唱樂隊中擔任鼓手,然後在羅伯特·舒曼音樂學院接受古典打擊樂手的正式訓練,這讓他的父母感到懊惱。在學習期間加入了多個團體——The Jokers、Sinus、音樂學院管弦樂隊——之後,他最終發現自己被邀請加入 Kraftwerk。 1975 年至 1990 年間,他是樂隊成員。 1990 年決定離開 Kraftwerk 後,巴托斯參與了各種合作項目,製作了自己的音樂,並擔任柏林藝術大學的客座教授。1 顯然,這本書讓內部人士深入了解 Kraftwerk 及其超越神話製造機器的創作過程。這包括許多音樂元素和技術選擇。例如,Bartos 反思了現場表演時 Portastudio 的使用,因為他們的音樂變得更加複雜: 我們播放的曲目是根據固定計劃分配的:例如,在《The Robots》中,曲目 1(與所有歌曲一樣)用於同步信號,曲目 2 是 Ralf 錄製的 Minimoog 貝司序列,曲目 3 是用於 Florian 的聲碼器,基本鼓模式位於曲目 4。正如我們在電視節目中的表現一樣,Ralf 在舞台上與 Florian 的聲碼器並行地跟著半回放演唱,講俄語部分並演奏。斷奏旋律在他的 Minimoog 上播放。我在合成器上現場提供了風琴,Wolfgang 在 Triggersumme 上打開了一些鼓填充,Florian 在頂部添加了現場聲碼器。在俄語部分,他與拉爾夫分享了電動機的聲音。順便說一句,在我們 1981 年的巡演中,我只在“Autobahn”中演奏電子打擊樂。 來源: 機器的聲音:我在發電廠及其他地方的生活 卡爾·巴托斯 巴托斯還揭示了一些與 Kraftwerk 相關的政治問題,例如版稅的分配、自行車和音樂之間的平衡,以及被禁止探索其他創意途徑。例如,他講述了當試圖記錄時事情發生的變化 科技流行樂,後續…

  • SwiftUI మాత్రమే చెడు యాప్‌లను డెవలప్ చేయడాన్ని సులభతరం చేస్తుంది

    ఆదివారం, 7 జూన్ 2026 పాలో ఆండ్రేడ్, గత నెలలో, “2026లో Mac-Assed యాప్‌ని రూపొందించడానికి SwiftUIని ఉపయోగించడం”: నేను ఇటీవలే Shopie యొక్క macOS వెర్షన్‌ను ప్రారంభించాను, ఈ యాప్‌ను నేను గత సంవత్సరం చివర్లో iOS యాప్ స్టోర్‌లో మొదటిసారి విడుదల చేసాను. మీరు కోరికల జాబితాలను సృష్టించడానికి మరియు ఉత్పత్తి ధర, లభ్యత మరియు ఇతర వివరాలు మారినప్పుడు మీకు తెలియజేయడం ద్వారా మీకు ఆసక్తి ఉన్న ఉత్పత్తులను ట్రాక్ చేయడంలో Shopie…

  • MCP to tylko podpowiedzi innych osób wskazujących na kod innych ludzi

    Od czasu, gdy wyszły protokoły kontekstowe (MCPS) (MCPS), ale nie mogłem całkiem ustalić idealnego, zwięzłego wyjaśnienia, dlaczego są tak dziwne pod względem zaufania. Po prostu go złamałem. Przypuszczalnie dzwoni API. MCP to podpowiedzi innych ludzi wskazujących nas na kod innych ludzi. Uchwycenie konkretnej troski Ludzie dużo mówią o bezpieczeństwie MCP, ale bez prawidłowego kadrowania. Czy…

  • Pengaturan Mac Baru 2025 Saya

    Saya menyiapkan Macbook Pro baru saya (14 inci, 2024 M4 Pro 24 GB RAM 500GB HD) hari ini (saya merekomendasikan lebih banyak memori tetapi ini bukan pilihan saya). Ini semua yang saya gunakan di Mac. Versi sebelumnya dari postingan ini: dari 2018-2020, 2021, 2022 dan 2023 dan 2024. Jika saya memperbarui postingan ini di masa…

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *