निष्क्रिय सीपीयू प्रक्रिया क्या करती है?

straceI के स्रोत को देखते हुए क्लोन ध्वज का उपयोग किया गया, CLONE_IDLETASKजिसे इस प्रकार वर्णित किया गया है:

#define CLONE_IDLETASK 0x00001000 /* kernel-only flag */

इसमें गहराई से देखने के बाद मैंने पाया कि, हालांकि यह ध्वज man cloneउसमें शामिल नहीं है, वास्तव में कर्नेल द्वारा बूट प्रक्रिया के दौरान मशीन पर प्रत्येक सीपीयू के लिए निष्क्रिय प्रक्रियाएं बनाने के लिए उपयोग किया जाता है (जिनमें सभी में PID 0 होना चाहिए)। यानी 8 सीपीयू वाली मशीन में कम से कम 7 (नीचे प्रश्न देखें) ऐसी प्रक्रियाएं "रनिंग" (नोट कोट्स) होंगी।

अब, यह मुझे उस प्रश्न के एक जोड़े की ओर ले जाता है जो "निष्क्रिय" प्रक्रिया वास्तव में करते हैं। मेरी धारणा यह है कि यह NOP ऑपरेशन को तब तक लगातार निष्पादित करता है जब तक कि इसकी समय सीमा समाप्त नहीं हो जाती है और कर्नेल एक बार फिर निष्क्रिय प्रक्रिया को चलाने या असाइन करने के लिए एक वास्तविक प्रक्रिया प्रदान करता है (यदि सीपीयू का उपयोग नहीं किया जा रहा है)। फिर भी, यह एक पूर्ण अनुमान है। इसलिए:

एक मशीन पर, कहते हैं, 8 सीपीयू 7 ऐसी निष्क्रिय प्रक्रियाएं बनाएंगे? (और एक सीपीयू कर्नेल द्वारा आयोजित किया जाएगा, जबकि कोई प्रदर्शन उपयोगकर्ता कार्य नहीं करेगा?)
क्या निष्क्रिय प्रक्रिया वास्तव में एनओपी परिचालनों की सिर्फ एक अनंत धारा है? (या एक लूप जो ऐसा ही करता है)।
क्या सीपीयू उपयोग (कहना uptime) की गणना केवल सीपीयू पर निष्क्रिय प्रक्रिया कितनी देर तक की गई थी और एक निश्चित अवधि के दौरान कितनी देर तक नहीं हुई थी?

_{PS यह संभावना है कि इस प्रश्न का एक अच्छा सौदा इस तथ्य के कारण है कि मुझे पूरी तरह से समझ में नहीं आता है कि सीपीयू कैसे काम करता है। यानी मैं असेंबली, टाइमफ्रेम और इंटरप्ट को समझता हूं, लेकिन मुझे नहीं पता कि कैसे, उदाहरण के लिए, एक सीपीयू कम या ज्यादा ऊर्जा का उपयोग कर सकता है जो उसके निष्पादन पर निर्भर करता है। मैं आभारी रहूंगा यदि कोई मुझे उस पर भी प्रकाश डाल सके।}

linux-kernel cpu

— grochmal
स्रोत

जब मैंने शीर्षक देखा तो मुझे "कुछ भी नहीं" लिखने के प्रलोभन का विरोध करना पड़ा।

— वैधता

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

— नेट

"एसीपीआई पावर स्टेट्स" भी देखें: ऐसे कई तरीके हैं, जिसमें एक प्रोसेसर निर्देशों को निष्पादित करना बंद कर सकता है, लेकिन फिर भी वह संभव नहीं है।

— pjc50

जवाबों:

निष्क्रिय कार्य का उपयोग प्रक्रिया लेखांकन के लिए किया जाता है, और ऊर्जा की खपत को कम करने के लिए भी। लिनक्स में, प्रत्येक प्रोसेसर के लिए एक निष्क्रिय कार्य बनाया जाता है, और उस प्रोसेसर पर लॉक किया जाता है; जब भी उस CPU पर चलने के लिए कोई अन्य प्रक्रिया नहीं होती है, तो निष्क्रिय कार्य निर्धारित होता है। निष्क्रिय कार्यों में बिताया गया समय "निष्क्रिय" समय के रूप में प्रकट होता है जैसे उपकरण top। (अपटाइम की गणना अलग तरीके से की जाती है।)

यूनिक्स को हमेशा लगता है कि किसी प्रकार का एक बेकार लूप पड़ा है (लेकिन जरूरी नहीं कि यह एक वास्तविक निष्क्रिय कार्य हो, गिल्स का जवाब देखें ), और यहां तक कि वी 1 में भी एक WAITनिर्देश का उपयोग किया गया था जो एक रुकावट आने तक प्रोसेसर को रोक देता था (यह "प्रतीक्षा के लिए खड़ा था" बीच में ")। कुछ अन्य ऑपरेटिंग सिस्टम ने विशेष रूप से विंडोज के व्यस्त छोरों, डॉस, ओएस / 2 और शुरुआती संस्करणों का उपयोग किया। काफी लंबे समय से, सीपीयू ने अपनी ऊर्जा खपत और गर्मी उत्पादन को कम करने के लिए इस तरह के "प्रतीक्षा" निर्देश का उपयोग किया है। आप arch/x86/kernel/process.cलिनक्स कर्नेल में उदाहरण के लिए निष्क्रिय कार्यों के विभिन्न कार्यान्वयन देख सकते हैं : मूल केवल कॉल करता हैHLT, जो एक अवरोध उत्पन्न होने तक प्रोसेसर को रोकता है (और C1 ऊर्जा-बचत मोड को सक्षम करता है), अन्य कार्यान्वयन विभिन्न बग्स या अक्षमताओं को संभालते हैं ( उदाहरण के लिए कुछ सीपीयू के MWAITबजाय उपयोग करना HLT)।

यह सब प्रक्रियाओं में निष्क्रिय राज्यों से पूरी तरह से अलग है, जब वे एक घटना (I / O आदि) की प्रतीक्षा कर रहे हैं।

— स्टीफन किट
स्रोत

हे, मैं इसे अब देखते हैं, धन्यवाद। play_dead()HALT को निष्पादित करने के लिए एक बहुत अच्छा mnemonic नाम है। क्या हर सीपीयू को HALT भेजने का कोई जोखिम नहीं होगा और फलस्वरूप फांसी होगी? (यानी उस स्थिति तक पहुँचने, हर सीपीयू, कर्नेल सही में एक बग हो जाएगा?)

— grochmal

CPU एक बाधा के माध्यम से HALT से उठता है।

— जोहान मायरेन

@ जोहानमेरेन - कूल, जो समझ में आता है। ऐसे मामले में भी इनपुट डिवाइस से एक IRQ रुकावट इसे वापस जगा देगा। धन्यवाद।

— grochmal

या अधिक मज़बूती से, टाइमर में बाधा ... (टिक रहित हैंडलिंग मछली की एक और केतली है।)

— स्टीफन किट

@EJP वास्तव में, यह एक बहुत ही सामान्य निर्देश है, भले ही इसके विभिन्न आर्किटेक्चर में अलग-अलग नाम हैं।

— इबिबिस

एक प्रक्रिया अनुसूचक की पाठ्यपुस्तक डिजाइन में, यदि अनुसूचक के पास अनुसूची करने की कोई प्रक्रिया नहीं है (यानी यदि सभी प्रक्रियाएँ अवरुद्ध हैं, इनपुट की प्रतीक्षा है), तो अनुसूचक प्रोसेसर के बाधित होने की प्रतीक्षा करता है। व्यवधान एक परिधीय (उपयोगकर्ता कार्रवाई, नेटवर्क पैकेट, एक डिस्क से पूरा पढ़ा हुआ), आदि से इनपुट का संकेत दे सकता है या एक टाइमर अवरोध हो सकता है जो एक प्रक्रिया में एक टाइमर को ट्रिगर करता है।

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

प्रतीक्षा-के-बीच का कार्य कैसे प्रोसेसर की क्षमताओं पर निर्भर करता है। सबसे बुनियादी प्रोसेसर डिजाइन के साथ, यह सिर्फ एक व्यस्त लूप है -

nothing:
    goto nothing

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

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

— गाइल्स
स्रोत

ध्यान दें कि एवीआर-आधारित माइक्रोकंट्रोलर्स जैसे सबसे बुनियादी एम्बेडेड सीपीयू में डब्ल्यूएफआई (वेट फॉर इंटरप्ट) निर्देश है, भले ही वह निर्देश सटीक मॉडल के आधार पर एनओपी के बराबर हो।

— जोनास स्चफर

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

— निक टी टी

@JonasWielicki एम्बेडेड सिस्टम के लिए डिज़ाइन किए गए आर्किटेक्चर बिजली प्रबंधन की देखभाल करते हैं इसलिए WFI वहां महत्वपूर्ण है। कई पुराने आर्किटेक्चर के पास ऐसी कोई चीज नहीं है। मूल 8086 आर्किटेक्चर ने AFAIR नहीं किया। क्या 68k में WFI है? क्या यह MIPS पर एक मानक विशेषता है? निम्न-स्तरीय प्रोग्रामिंग के साथ मेरा परिचय ज्यादातर एआरएम पर है, जहां कम बिजली की खपत बेशक होती है और डब्ल्यूएफआई केवल पावर मैनेजमेंट आइसबर्ग का टिप है।

— गिल्स

@ गिल्स 8086 में ठहराव का निर्देश था। En.m.wikipedia.org/wiki/HLT_(x86_instruction) देखें अनुदेश में केवल 80486 DX4 के बाद से बिजली की बचत कार्यक्षमता शामिल थी। इतिहास में वापस देखें तो एचएलटी पहले से ही 8080 और व्युत्पन्न (जैसे Z80) था।

— पाबौक

HLTDX4 के बाहर आने से पहले @pabouk 386 और 486 के SL वेरिएंट को पावर कर सकता है (विकिपीडिया लेख गलत है)।

— स्टीफन किट

नहीं, एक निष्क्रिय कार्य सीपीयू चक्रों को बर्बाद नहीं करता है। अनुसूचक बस निष्पादन के लिए एक निष्क्रिय प्रक्रिया का चयन नहीं करता है। एक निष्क्रिय प्रक्रिया किसी घटना के होने की प्रतीक्षा कर रही है ताकि यह जारी रह सके। उदाहरण के लिए, यह एक read()सिस्टम कॉल में इनपुट की प्रतीक्षा कर सकता है ।

वैसे, कर्नेल एक अलग प्रक्रिया नहीं है। कर्नेल कोड को हमेशा एक प्रक्रिया के संदर्भ में निष्पादित किया जाता है (अच्छी तरह से, एक कर्नेल थ्रेड के विशेष मामले को छोड़कर), इसलिए यह कहना सही नहीं है "और एक सीपीयू कर्नेल द्वारा ही आयोजित किया जाएगा, जबकि कोई प्रदर्शन उपयोगकर्ता कार्य नहीं करेगा"।

— जोहान मायरेन
स्रोत

हम्मम ... मुझे नहीं लगता कि यह उस प्रकार की निष्क्रिय प्रक्रिया है जो CLONE_IDLETASK द्वारा बनाई गई है। अगर ऐसा होता है, तो इसे बिल्कुल भी बनाने की आवश्यकता नहीं होगी, अर्थात अनुसूचक ने सीपीयू पर कर्नेल निष्क्रिय प्रक्रियाओं को अनदेखा कर दिया था, बूट के दौरान उनके लिए किसी भी प्रक्रिया को बनाने की आवश्यकता नहीं होगी। (डीडब्ल्यू मेरा नहीं है, हालांकि :))

— ग्रूम्मल

एक छोटी सी गुगली से पता चलता है कि CLONE_IDLETASK एक कर्नेल-आंतरिक ध्वज है जिसे 2002 में कर्नेल संस्करण 2.5.14 के आसपास पेश किया गया था और बाद में इसे 2004 में हटा दिया गया।

— जोहान मायरेन

"एक" निष्क्रिय प्रक्रिया नहीं बल्कि " " निष्क्रिय प्रक्रिया।

— इमीबिस