गड़बड़ी का कोड: E3000

कैटगरी: कंपाइल करने में लगने वाला समय: SparseCore Allocation Failure

यह गड़बड़ी तब होती है, जब XLA:SparseCore कंपाइलर, मौजूदा SparseCore प्रोग्राम के लिए ज़रूरी मेमोरी स्पेस में मेमोरी का लगातार ब्लॉक असाइन नहीं कर पाता.

गड़बड़ी के मैसेज के उदाहरण:

INTERNAL:Failed to run pass pipeline. Hlo-Op: result.1:279:1: error: 'memref.alloca' op current allocation offset upper bound (140704 words) exceeds the legitimate user allocatable offset upper bound (131071 words) in memory space 201 when allocating 23440 words. result.1:279:1: note: see current operation: %232 = "memref.alloca"() <{operandSegmentSizes = array<i32: 0, 0>}> : () -> memref<23440xf32, 201>

XLA बैकएंड: टीपीयू

खास जानकारी

SparseCore (एससी), स्पार्स वर्कलोड के लिए खास प्रोसेसर है. यह डेटा को बेहतर तरीके से मैनेज करने के लिए, मेमोरी के खास क्रम पर निर्भर करता है. XLA कंपाइलर, हार्डवेयर की सीमाओं और उपयोगकर्ता के तय किए गए साइज़ के आधार पर, बफ़र का साइज़ तय करने और उन्हें स्टैटिक तौर पर असाइन करने की कोशिश करता है. इस गड़बड़ी से पता चलता है कि मेमोरी के बंटवारे के इस चरण के दौरान, आउट ऑफ़ मेमोरी (ओओएम) की स्थिति है.

गड़बड़ी के मैसेज में आम तौर पर मेमोरी स्पेस का आईडी दिया जाता है. यहां मेमोरी स्पेस और उनके पूर्णांक एन्कोडिंग दिए गए हैं:

एससी और इसकी मेमोरी के क्रम के बारे में ज़्यादा जानने के लिए, SparseCore के दस्तावेज़ पढ़ें.

डीबग करना

समस्या हल करने का तरीका इस बात पर निर्भर करता है कि मेमोरी के किस हिस्से में जगह नहीं है.

पहली स्थिति. एचबीएम के बंटवारे से जुड़ी गड़बड़ियां

मेमोरी स्पेस का आईडी: 203

यह गड़बड़ी तब होती है, जब SparseCore प्रोग्राम के ज़रिए अनुरोध किया गया कोई एक अस्थायी असाइनमेंट, उपलब्ध एचबीएम में फ़िट होने के लिए बहुत बड़ा होता है. स्टैंडर्ड एम्बेडिंग वर्कलोड और एससी ऑफलोड किए गए कलेक्टिव में, हर कोर के लिए बहुत बड़े पार्टीशन या गलत शार्डिंग स्पेसिफ़िकेशन की वजह से, कंपाइलर को बड़े बफ़र का अनुरोध करना पड़ सकता है.

सुझाई गई कार्रवाइयां:

• शार्डिंग की जांच करें: पक्का करें कि आपकी एम्बेडिंग टेबल और एससी इनपुट/आउटपुट टेंसर सही तरीके से बांटे गए/शार्ड किए गए हों. अगर कोई एक कोर बहुत ज़्यादा डेटा के लिए ज़िम्मेदार है, तो हो सकता है कि डेटा को सही तरीके से बांटा न जा सके.
• सीमाओं में बदलाव करना: max_ids_per_partition और max_unique_ids_per_partition की समीक्षा करें. अगर इन्हें ज़रूरत से ज़्यादा सेट किया जाता है, तो कंपाइलर, ज़रूरत से ज़्यादा मेमोरी रिज़र्व कर लेता है. सीमाएं, टेबल में कैसे दिखती हैं लेख पढ़ें.

परिदृश्य 2. डिवाइस की मेमोरी में गड़बड़ियां

मेमोरी स्पेस आईडी: 0, 201, 202, 204

Smem, TileSpmem, Spmem या सिंक फ़्लैग में मेमोरी असाइन करने में गड़बड़ियां आम तौर पर कंपाइलर की गड़बड़ियों या मेमोरी असाइन करने की रणनीति की सीमाओं की वजह से होती हैं. इनमें कंपाइलर, मेमोरी की सभी ज़रूरी शर्तों को पूरा नहीं कर पाता.

सुझाई गई कार्रवाइयां:

1. XLA ऑपरेशन में गड़बड़ी की वजह का पता लगाना: गड़बड़ी की वजह बनने वाले किसी खास एससी एचएलओ या मोज़ेक कर्नल का पता लगाने के लिए, इंटरमीडिएट कंपाइलर के रिप्रज़ेंटेशन जनरेट करें:
   • Dump SparseCore MLIR: फ़्लैग --xla_sc_dump_mlir_to=/path/to/dump को सेट करें. इससे SparseCore प्रोग्राम का एमएलआईआर जनरेट होता है. इससे यह देखा जा सकता है कि कौनसा असाइनमेंट साइज़, गड़बड़ी के मैसेज से मेल खाता है.
   • Dump Mosaic LLO: कस्टम कर्नल के लिए, --xla_mosaic_dump_to=/path/to/dump का इस्तेमाल करके, Mosaic से जनरेट किए गए सभी Low Level Optimizer (LLO) प्रोग्राम की जांच करें.
2. स्क्रैच साइज़ कम करें (Pallas का इस्तेमाल करने वाले लोग): अगर Mosaic कर्नल में गड़बड़ी होती है, तो scratch_shapes कॉन्फ़िगरेशन की समीक्षा करें. पक्का करें कि आपके pltpu.SMEM अनुरोध, टीपीयू जनरेशन के लिए तय की गई हार्डवेयर की खास बातों के मुताबिक हों.
3. कलेक्टिव ऑफ़लोडिंग की सुविधा बंद करें: अगर गड़बड़ी, SC ऑफ़लोड किए गए कलेक्टिव ऑपरेशन की वजह से आ रही है, तो SC ऑफ़लोडिंग की सुविधाओं को बंद करके देखें:
   • --xla_tpu_enable_sparse_core_collective_offload_all_gather=false
   • --xla_tpu_enable_sparse_core_collective_offload_all_reduce=false
4. बग की शिकायत करें: अगर ऊपर दिए गए चरणों से समस्या हल नहीं होती है, तो हो सकता है कि यह कंपाइलर का बग हो. कृपया गड़बड़ी की रिपोर्ट दर्ज करें.