एकाधिक कोर पर बैश के साथ पाइप प्रक्रियाओं को कैसे चलाया जाए?

Question

मेरे पास एक साधारण बैश स्क्रिप्ट है जो एक प्रक्रिया के दूसरे भाग में पाइप आउटपुट करती है। अर्थात् :.

dostuff | filterstuff 

ऐसा होता है कि मेरे Linux सिस्टम पर (openSUSE यह मायने रखता है, तो गिरी 2.6.27) इन दोनों एक सिंगल कोर पर चलने संसाधित करता है। हालांकि, अलग-अलग कोर पर प्रक्रिया प्रक्रियाएं एक डिफ़ॉल्ट नीति है जो इस मामले में ट्रिगर नहीं होती है।

उस के लिए सिस्टम का कौन सा घटक ज़िम्मेदार है और मल्टीकोर सुविधा का उपयोग करने के लिए मुझे क्या करना चाहिए?

नोट कि 2.6.30 कर्नेल पर ऐसी कोई समस्या नहीं है।

स्पष्टीकरण: Dennis Williamson की सलाह का पालन करने के बाद, मैं शीर्ष कार्यक्रम के साथ यकीन बनाया, पहुंचाया कि प्रक्रियाओं वास्तव में हमेशा एक ही प्रोसेसर पर रन कर रहे हैं। लिनक्स शेड्यूलर, जो आमतौर पर वास्तव में अच्छी नौकरी करता है, इस बार ऐसा नहीं करता है।

मुझे लगता है कि बैश में कुछ ओएस को ऐसा करने से रोकता है। बात यह है कि मुझे बहु-कोर और एकल-कोर मशीनों के लिए पोर्टेबल समाधान की आवश्यकता है। tasksetsolutionDennis Williamson द्वारा प्रस्तावित एकल-कोर मशीनों पर काम नहीं करेगा। वर्तमान में मैं उपयोग कर रहा हूँ :,

dostuff | taskset -c 0 filterstuff 

लेकिन यह एक गंदा हैक की तरह लगता है। क्या कोई बेहतर समाधान प्रदान कर सकता है?

Answer 1

मान लीजिए dostuff एक सीपीयू पर चल रहा है। यह डेटा को एक पाइप में लिखता है, और वह डेटा उस सीपीयू पर कैश में होगा। चूंकि filterstuff उस पाइप से पढ़ रहा है, शेड्यूलर इसे उसी CPU पर चलाने का निर्णय लेता है, ताकि उसका इनपुट डेटा कैश में हो।

अपने कर्नेल CONFIG_SCHED_DEBUG=y के साथ बनाया गया है, तो

# echo NO_SYNC_WAKEUPS > /sys/kernel/debug/sched_features

heuristics के इस वर्ग अक्षम करना चाहिए। (अन्य शेड्यूलर ट्यूनेबल के लिए /usr/src/linux/kernel/sched_features.h और /proc/sys/kernel/sched_* देखें।)

हैं कि मदद करता है और समस्या अभी भी एक नया कर्नेल, और यह वास्तव में तेजी से एक सीपीयू से अलग CPUs पर चलाने के लिए किया है के साथ होता है, तो कृपया लिनक्स कर्नेल मेलिंग सूची के लिए समस्या की रिपोर्ट ताकि वे समायोजित कर सकते हैं उनके heuristics।

Answer 2

इस एक सीपीयू (प्रोसेसर) आत्मीयता स्थापित करने के लिए आजमाएँ:

taskset -c 0 dostuff | taskset -c 1 filterstuff 

संपादित करें:

• एक फ़ाइल बनाने के proctest कहा जाता है और chmod +x proctest:

  इस प्रयोग की कोशिश करो सामग्री के साथ:

  #!/bin/bash 
  while true 
  do 
      ps 
      sleep 2 
  done 
  

• इस चल रहा शुरू:,

  ./proctest | grep bash 
  

एक और टर्मिनल में
• शीर्ष शुरू - यकीन है कि यह% सीपीयू द्वारा छँटाई है
• को कुछ सेकंड के लिए समझौता करते हैं, फिर
• मुद्दा आदेश छोड़ने ps u

• उच्चतम कई प्रक्रियाओं के पीआईडी ​​की सूची के साथ top -p शुरू करें, उनमें से 8 कहें, top से अधिक स्क्रीन पर छोड़े गए सूची से 01 के लिए च तो जे तो अंतरिक्ष

प्रेस -

top -p 1234, 1255, 1211, 1212, 1270, 1275, 1261, 1250, 16521, 16522 

• प्रोसेसर फ़ील्ड जोड़ें: -और grep जो ps द्वारा सूचीबद्ध किए गए सभी अल्पविराम के द्वारा अलग है, इसलिए की तरह (क्रम आवश्यक नहीं है)
• पीआईडी ​​को तरह सेट - प्रेस Shift + एफ तो एक तो अंतरिक्ष
• वैकल्पिक: प्रेस धागा दृश्य
• वैकल्पिक चालू करने के लिए शिफ्ट + एच: प्रेस घ और टाइप .09 और दर्ज थोड़ी देर समय
• अब सेट को देखने के लिए इस कदम प्रोसेस किए जाते प्रेस प्रोसेसर से प्रोसेसर तक, आपको proctest और grep बाउंस देखना चाहिए, कभी-कभी एक ही प्रोसेसर पर, कभी-कभी अलग-अलग

Answer 3

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

यदि आपके पास दो कार्य हैं जो सीपीयू पर चलाने के लिए वास्तव में तैयार हैं, तो मैं उन्हें अलग-अलग कोर (कुछ बिंदु पर) पर निर्धारित करने की अपेक्षा करता हूं।

मेरा अनुमान है, क्या होता है कि पाइप बफर पूर्ण होने तक डोस्टफ चलता है, जिस बिंदु पर यह और नहीं चला सकता है, इसलिए "फ़िल्टरस्टफ" प्रक्रिया चलती है, लेकिन यह इतनी कम समय के लिए चलती है कि डोस्टफ जब तक फ़िल्टरस्टफ ने पूरे पाइप बफर को फ़िल्टर करना समाप्त नहीं किया है, तब तक पुन: निर्धारित नहीं किया जाता है, जिस बिंदु पर डोस्टफ फिर से निर्धारित हो जाता है।