jemalloc, mmap और साझा स्मृति?

Question

jemalloc साझा स्मृति से आवंटित करने के लिए संशोधित किया जा सकता है? फ्रीबीएसडी फ़ंक्शन dallocx() का तात्पर्य है कि आप आवंटन के लिए उपयोग करने के लिए एक पॉइंटर प्रदान कर सकते हैं, लेकिन को सभी उस स्मृति से आवंटन (न ही आकार सेट करें) प्रतिबंधित करने के लिए jemalloc को बताने का एक स्पष्ट तरीका दिखाई नहीं देता है।

dallocx() समारोह स्मृति ptr द्वारा संदर्भित करने के लिए भविष्य आवंटन के लिए उपलब्ध कराया जा कारण बनता है।

यदि नहीं, तो ऐसी सुविधा के लिए प्रयास का स्तर क्या है? मैं एक ऑफ-द-शेल्फ आवंटन योजना खोजने के लिए संघर्ष कर रहा हूं जो मैंने प्रदान किए गए साझा स्मृति अनुभाग से आवंटित कर सकते हैं।

इसी प्रकार, jemalloc को स्वैपिंग रोकने के लिए स्मृति के लॉक क्षेत्र से आवंटित करने के लिए कॉन्फ़िगर किया जा सकता है?

मुझे प्रासंगिक कोड अनुभागों को इंगित करने के लिए स्वतंत्र महसूस करें जिन्हें संशोधन की आवश्यकता है और कोई विचार या सुझाव प्रदान करते हैं।

विचार मैं तलाश कर रहा हूँ - जब से तुम एक थ्रेडेड वातावरण में आवंटित करने के लिए एरेनास/ढेर बना सकते हैं क्योंकि jemalloc विवाद को कम करने के करता है, अवधारणा एक बहु वातावरण में साझा स्मृति के क्षेत्रों के आवंटन के लिए स्केलेबल लगता है, यानी मैं बना mmap() का उपयोग करके साझा मेमोरी के एन क्षेत्र, और मैं jemalloc (या किसी भी आवंटन योजना) की शक्ति का लाभ उठाने के लिए जितना संभव हो उतना कुशलतापूर्वक आवंटित करना चाहता हूं, न्यूनतम थ्रेड विवाद, उन साझा क्षेत्रों में से एक, यानी थ्रेड/प्रक्रियाएं नहीं हैं समान साझा क्षेत्रों और क्षेत्रों तक पहुंचने के लिए, विवाद की संभावना न्यूनतम है और malloc ऑपरेशन की गति में वृद्धि हुई है।

यह malloc() एपीआई के साथ वैश्विक पूल आवंटन से अलग है क्योंकि आमतौर पर इन्हें वैश्विक लॉक को उपयोगकर्ता-स्थान को प्रभावी ढंग से क्रमबद्ध करने की आवश्यकता होती है। मैं इससे बचना चाहता हूं।

संपादित 2:

आदर्श रूप में इस तरह की एक एपीआई:

// init the alloc context to two shmem pools 
ctx1 = alloc_init(shm_region1_ptr); 
ctx2 = alloc_init(shm_region2_ptr); 

(... bunch of code determines pool 2 should be used, based on some method 
of pool selection which can minimize possibility of lock contention 
with other processes allocating shmem buffers) 

// allocate from pool2 
ptr = malloc(ctx2, size) 

Answer 1

हां। लेकिन जब आपने सवाल पूछा तो यह सच नहीं था।

जेमलोक 4 (2015 के अगस्त में जारी) में कुछ mallctl नामस्थान हैं जो इस उद्देश्य के लिए उपयोगी होंगे; वे आपको प्रति-क्षेत्र, एप्लिकेशन-विशिष्ट खंड आवंटन हुक निर्दिष्ट करने की अनुमति देते हैं। विशेष रूप से, arena.<i>.chunk_hooks नामस्थान और arenas.extendmallctl विकल्प उपयोग के हैं। एक integration test मौजूद है जो दर्शाता है कि इस API का उपभोग कैसे करें।

तर्क के संबंध में, मैं उम्मीद करता हूं कि प्रभावी "मैसेजिंग" ओवरहेड को यह समझने की आवश्यकता है कि किसी भी विशेष मेमोरी सेगमेंट पर विवाद कहां है, जो कि सिर्फ दंड के ऊपर की ओर बढ़ने के समान होगा, क्योंकि आप किसी विशेष क्षेत्र के "विवाद" मान को सटीक रूप से अपडेट करने के लिए कैश लाइन।

चूंकि जेमलोक पहले से ही विवाद को कम करने के लिए कई तकनीकों का उपयोग करता है, इसलिए आप opt.narenas के साथ अतिरिक्त क्षेत्र बनाकर एक उच्च थ्रेड वाले वातावरण में एक समान व्यवहार प्राप्त कर सकते हैं। इससे विवाद कम हो जाएगा क्योंकि कम धागे को मैदान में मैप किया जाएगा, लेकिन चूंकि धागे प्रभावी ढंग से गोल-लुप्त होते हैं, इसलिए संभव है कि आप हॉट-स्पॉट्स को वैसे भी प्राप्त करें।

इसके आस-पास पहुंचने के लिए, आप अपनी विवाद गिनती और हॉटस्पॉट पहचान कर सकते हैं, और कम विवाद के साथ किसी क्षेत्र पर धागे को स्विच करने के लिए बस thread.arenamallctl इंटरफ़ेस का उपयोग करें।