हमें I / O की प्रतीक्षा क्यों करनी होगी?

Question

यह हमेशा से ज्ञात है कि डिस्क संचालन धीमा है और हम कारण जानते हैं कि वे धीमी क्यों हैं। तो यहाँ सवाल यह है कि हमें I / O की प्रतीक्षा क्यों करनी है या IOWait, आदि जैसी कोई चीज़ क्यों है?

मेरा मतलब है कि मैंने देखा है कि जब आप पृष्ठभूमि में कुछ I / O कार्य कर रहे होते हैं, तो आपका कंप्यूटर मूल रूप से बहुत धीमा हो जाता है, मैंने विशेष रूप से देखा है कि लिनक्स का उपयोग करते समय, यदि आप कुछ लंबे समय तक I / O कार्य कर रहे हैं ओएस पूरा होने तक लगभग अनुपयोगी हो जाता है।

वास्तव में, मैंने इस विषय को एक लेख में भी पाया है, एक स्निपेट है:

I / O प्रतीक्षा 12.1% है। इस सर्वर में 8 कोर हैं (बिल्ली / proc / cpuinfo के माध्यम से)। यह बहुत करीब है (1/8 कोर = 0.125)

तो मूल रूप से इसका मतलब है कि यह कंप्यूटर को बहुत कम कर रहा है, ऐसा क्यों है? मेरा मतलब ठीक है, अब सामान्य कंप्यूटर कम से कम 2 कोर हैं, कभी-कभी 4 या कभी-कभी उनके पास हाइपरथ्रेडिंग या ऐसा कुछ होने के कारण अधिक होता है। लेकिन अब सवाल यह है कि सीपीयू को वास्तव में वहां रहना है, व्यावहारिक रूप से आईओ के इंतजार के अलावा कुछ और नहीं कर रहा है? मेरा मतलब है कि प्रक्रिया प्रबंधन के मूल विचार या वास्तुकला, अब मुझे नहीं पता कि क्या यह ओएस है जो इसके लिए जिम्मेदार है, या क्या यह हार्डवेयर भाग में आता है, लेकिन इसे सीपीयू के लिए इंतजार करना या इंतजार करना संभव बनाया जाना चाहिए नियमित रूप से जांचें, जबकि वास्तव में बहुत सारे अन्य कार्य करते हैं और केवल IO प्रक्रिया में वापस जाते हैं जब यह तैयार होता है। वास्तव में, अगर ऐसा मुश्किल काम है और सीपीयू को इंतजार करना होगा, तो क्यों ' t कि हार्डवेयर द्वारा और अधिक कुशलता से प्रबंधित तो? उदाहरण के लिए किसी तरह का मिनी सीपीयू हो सकता है, जो इसके लिए इंतजार करेगा और डेटा के छोटे हिस्से को वास्तविक सीपीयू तक पहुंचाएगा, जैसे ही यह प्रक्रिया में वापस आएगा और इसलिए प्रक्रिया दोहराई जाएगी और हमारे पास नहीं होगी व्यावहारिक रूप से डेटा कॉपी प्रक्रिया के लिए एक संपूर्ण सीपीयू कोर समर्पित करें ... या क्या मैं वह हूं जो इस तरह के सामान का आविष्कार करना चाहिए और उसके लिए एक अच्छा पुरस्कार प्राप्त करना चाहिए? : एस

अब ठीक है, मैं वास्तव में इसे अब एक पर्यवेक्षक के दृष्टिकोण से डाल रहा हूं और मैं वास्तव में इस विषय में गहराई से नहीं गया हूं, लेकिन मुझे वास्तव में समझ नहीं आया कि सीपीयू को एचडीडी की गति के साथ काम क्यों करना है, जबकि यह बस हो सकता है कुछ और करें और तैयार होने के बाद एचडीडी में वापस आएं। यह विचार उस एप्लिकेशन को गति देने के लिए नहीं है, जिन्हें उस IO ऑपरेशन या कॉपी प्रक्रिया या जो भी की आवश्यकता है, लेकिन विचार उस ऑपरेशन को करते समय CPU खपत को न्यूनतम रूप से प्रभावित करना है, ताकि OS अन्य प्रक्रियाओं और उपयोगकर्ता के लिए इसका उपयोग कर सके। सामान्य कंप्यूटर लैग को महसूस नहीं करना होगा, जब कुछ प्रतिलिपि करने का काम ...

Comments

"जबकि यह सिर्फ कुछ और कर सकता था" - जैसे कि? इसके लिए डेटा के साथ काम करने की जरूरत है। यदि वह डेटा CPU L1 कैश में नहीं है, तो उसे L2 कैश से प्राप्त करना होगा। यदि L2 कैश में नहीं है, तो उसे L3 से प्राप्त करना होगा (यदि इसमें एक है)। यदि यह मरने वाले कैश पर बिल्कुल नहीं है, तो इसे मुख्य मेमोरी तक पहुंचने की आवश्यकता है। यदि मुख्य मेमोरी में नहीं है ... HDD को एक्सेस करने की आवश्यकता है।

— ओड

कंप्यूटर कुछ और करता है; कर्नेल थ्रेड को ब्लॉक करता है जब तक कि आईओ ऑपरेशन पूरा नहीं होता है, जिससे अन्य थ्रेड / प्रक्रियाएं चलती हैं। लेकिन अगर सब कुछ डिस्क IO पर इंतजार कर रहा है, तो ऐसा करने के लिए और कुछ नहीं है।

— कर्नल थर्टी टू

आप कार्यक्रमों के लिए I / O टॉवर तक पहुँचने के लिए प्रतीक्षा करेंगे और आपको उनके फ्रिस्बे भेजेंगे!

— आलमो

@immibis सही! :)

— आलमो

आमतौर पर आधुनिक OSes वही करते हैं जो आप शिकायत कर रहे हैं कि वे ऐसा नहीं करते हैं - IO संचालन को उपयुक्त हार्डवेयर में भेजा जाता है और हार्डवेयर द्वारा व्यवधान उत्पन्न किया जाता है ताकि यह संकेत दिया जा सके कि संचालन किया जाता है। IO पर प्रतीक्षा की जाने वाली प्रक्रियाएं आमतौर पर प्रतीक्षा करते समय अवरुद्ध हो जाती हैं (इसे बदला जा सकता है)। यदि कई प्रक्रियाएं IO पर प्रतीक्षा कर रही हैं और सीपीयू के लिए कोई अन्य प्रक्रिया कुछ भी नहीं है तो करने के लिए बहुत कुछ नहीं है। आप मेम-स्वैप नरक में भी समाप्त हो सकते हैं। CPU, मेमोरी और IO को कुशलतापूर्वक उपयोग करने के लिए प्रोग्राम लिखना विशेष कौशल की आवश्यकता होती है, और जो चल रहा है वह भी प्रभाव डालता है जो सबसे अच्छा काम करता है।

— nategoose

Answer 1

आप जिन I / O योजनाओं का वर्णन कर रहे हैं, वे कंप्यूटर में वर्तमान उपयोग में हैं।

क्यों सीपीयू वास्तव में वहाँ रहना है, व्यावहारिक रूप से सिर्फ आईओ के इंतजार के अलावा और कुछ नहीं कर रहा है?

: यह सरल संभव आई / ओ विधि है क्रमादेशित आई / ओ । कई एम्बेडेड सिस्टम और कम / अंत माइक्रोप्रोसेसरों में केवल एक इनपुट निर्देश और एक एकल आउटपुट निर्देश है। प्रोसेसर को पढ़े या लिखे हर वर्ण के निर्देशों का स्पष्ट अनुक्रम निष्पादित करना चाहिए।

लेकिन यह सीपीयू के लिए प्रतीक्षा करने या नियमित रूप से जांच करने के लिए संभव बनाया जाना चाहिए, जबकि वास्तव में बहुत सारे अन्य कार्य करना और केवल IO प्रक्रिया में वापस जाना जब यह तैयार हो जाए

कई व्यक्तिगत कंप्यूटरों में अन्य I / O योजनाएं हैं। डिवाइस के तैयार होने ( व्यस्त प्रतीक्षा ) के लिए एक तंग लूप में प्रतीक्षा करने के बजाय , सीपीयू आई / ओ डिवाइस को शुरू करने के लिए कहता है जब यह किया जाता है तो एक बाधा उत्पन्न करने के लिए ( बाधित संचालित आई / ओ )।

हालाँकि व्यवधान से प्रेरित I / O एक कदम आगे है (क्रमादेशित I / O की तुलना में), इसके लिए संचारित प्रत्येक वर्ण के लिए एक व्यवधान की आवश्यकता होती है और यह है ...

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

कई समस्याओं का हल किसी और के काम में होने से है! :-)

डीएमए कंट्रोलर / चिप (डायरेक्ट मेमोरी एक्सेस) प्रोग्राम्ड I / O की अनुमति देता है, लेकिन किसी और के पास होने से!

डीएमए के साथ सीपीयू को केवल कुछ रजिस्टरों को इनिशियलाइज़ करना होता है और ट्रांसफर ख़त्म होने तक यह कुछ और करने के लिए स्वतंत्र है (और एक रुकावट खड़ी हो जाती है)।

यहां तक ​​कि डीएमए भी पूरी तरह से मुक्त नहीं है: उच्च गति वाले डिवाइस मेमोरी रेफरेंस और डिवाइस संदर्भ ( साइकिल चोरी ) के लिए कई बस चक्रों का उपयोग कर सकते हैं और सीपीयू को इंतजार करना पड़ता है (डीएमए चिप में हमेशा उच्च बस प्राथमिकता होती है)।

I / O प्रतीक्षा 12.1% है। इस सर्वर में 8 कोर हैं (बिल्ली / proc / cpuinfo के माध्यम से)। यह बहुत करीब है (1/8 कोर = 0.125)

मुझे लगता है कि यह है: डिस्क I / O को समझना - आपको कब चिंतित होना चाहिए?

खैर यह अजीब नहीं है: सिस्टम (mySQL) को डेटा में हेरफेर करने से पहले सभी पंक्तियों को प्राप्त करना चाहिए और अन्य गतिविधियां नहीं हैं।

यहाँ कंप्यूटर आर्किटेक्चर / OS समस्या नहीं है। यह उदाहरण कैसे सेट किया गया है।

अधिकांश पर यह एक RDBMS ट्यूनिंग समस्या या SQL क्वेरी समस्या (अनुपलब्ध अनुक्रमणिका, खराब क्वेरी योजना, खराब क्वेरी ...) हो सकती है

Answer 2

अतुल्यकालिक IO लिखना संभव है, जहां आप OS को डिस्क रीड / राइट भेजने के लिए कहते हैं और फिर कुछ और करते हैं और बाद में जांच करते हैं कि क्या हुआ है। यह नए से बहुत दूर है। एक पुरानी विधि IO के लिए एक और थ्रेड का उपयोग कर रही है।

हालाँकि इसके लिए यह आवश्यक है कि आपके पास कुछ ऐसा हो जो पढ़े जाने के दौरान निष्पादित हो और परिणाम के लिए आपके द्वारा पारित बफर को छूने की अनुमति न हो।

जब आप सब कुछ IO को रोकते हैं, तो यह प्रोग्राम करना बहुत आसान है।

जब आप एक अवरुद्ध पठन फ़ंक्शन को कॉल करते हैं, तो आप जानते हैं कि यह तब तक वापस नहीं आएगा जब तक कि कुछ पढ़ा नहीं गया हो और इसके तुरंत बाद आप उस पर प्रसंस्करण शुरू कर सकते हैं।

ठेठ पढ़ा पाश एक अच्छा उदाहरण है

//variables that the loop uses
char[1024] buffer;
while((read = fread(buffer, 1024, 1, file))>0){
    //use buffer
}

अन्यथा आपको वर्तमान फ़ंक्शन स्थिति (आमतौर पर कॉलबैक + उपयोगकर्ता दाता पॉइंटर के रूप में) को बचाने और इसे पढ़ने के ऑपरेशन के + पहचानकर्ता को एक select()प्रकार के लूप तक वापस पास करने की आवश्यकता है । यदि कोई ऑपरेशन समाप्त हो जाता है, तो यह कॉलबैक + डेटा पॉइंटर पर रीड ऑपरेशन के पहचानकर्ता को मैप करेगा और कॉल किए गए ऑपरेशन की जानकारी के साथ कॉलबैक को आमंत्रित करेगा।

void callback(void* buffer, int result, int fd, void* userData){
    if(result<=0){
    //done, free buffer and continue to normal processing
    }
    //use buffer

    int readID = async_read(fd, buffer, userData->buff_size);
    registerCallback(readId, callback, userData);
}

इसका अर्थ यह भी है कि प्रत्येक फ़ंक्शन जो कि async रीड का उपयोग करके समाप्त हो सकता है, उसे async निरंतरता को संभालने में सक्षम होना चाहिए। यह अधिकांश कार्यक्रमों में एक गैर-तुच्छ परिवर्तन है, आप लोगों से उस बारे में async C # में आने का प्रयास करने को कहते हैं।

---

हालांकि तुल्यकालिक IO बनाम अतुल्यकालिक IO सामान्य मंदी का कारण नहीं है। इन पेजों की अदला-बदली भी एक ऐसा ऑपरेशन है जिसके लिए IO पर इंतजार करना पड़ता है। शेड्यूलर किसी अन्य प्रोग्राम पर स्विच करेगा जो IO पर प्रतीक्षा नहीं कर रहा है यदि एक है ( IO प्रतीक्षा है जब प्रोसेसर निष्क्रिय है और एक IO ऑपरेशन लंबित है )।

असली समस्या यह है कि हार्डड्राइव और सीपीयू दोनों रैम के साथ संचार करने के लिए एक ही चैनल का उपयोग करते हैं ; मेमोरी बस। और जब तक आप RAID का उपयोग नहीं कर रहे हैं तब तक डेटा प्राप्त करने के लिए केवल एक ही डिस्क है। यह बदतर बना दिया जाता है यदि आप ग्राफिक्स गहन अनुप्रयोग का उपयोग कर रहे हैं, तो GPU के साथ संचार भी हस्तक्षेप करेगा।

दूसरे शब्दों में असली अड़चन शायद हार्डवेयर में है, बल्कि सॉफ्टवेयर में।

Comments

"हालांकि तुल्यकालिक IO बनाम अतुल्यकालिक IO सामान्य मंदी का कारण नहीं है।" तो जब आप मूल बातें के बारे में सवाल उठाते हैं तो आपने इस अपेक्षाकृत उन्नत विषय पर ध्यान केंद्रित करने का निर्णय क्यों लिया?

— svick

आपको शायद DMA के बारे में कुछ उल्लेख करना चाहिए

— एलेक टीले

मजेदार तथ्य: वास्तव में एक बहुत पुराना तंत्र है जो कॉलबैक से निपटने के बिना I / O करते समय कार्यक्रमों को कुछ और करने देता है; इसे थ्रेड्स कहा जाता है ।

— user253751

सिंक / async IO के पेशेवरों / विपक्षों की अच्छी चर्चा। लेकिन क्या आप सुनिश्चित हैं कि मंदी का कारण है? आम तौर पर मुझे लगता है कि भारी IO लोड के तहत मंदी पहले खराब-आर्किटेक्चर सॉफ्टवेयर के कारण होती है, या जब ऐसा नहीं होता है, क्योंकि सिस्टम एकल, धीमी डिस्क (यानी गैर-एसएसडी) का उपयोग कर रहा है, और सब कुछ समवर्ती रूप से उपयोग करने की कोशिश कर रहा है । इससे पहले कि मैं मेमोरी बस की संतृप्ति पर दोष लगाऊं, डिस्क की सेवा अनुरोध करने की क्षमता पर एक अड़चन का दोष लगाऊंगा। आपको एक आधुनिक मेमोरी बस को संतृप्त करने के लिए वास्तव में उच्च-अंत भंडारण की आवश्यकता है ।

— अरथ

Answer 3

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

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

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

I / O करते समय अन्य सामान को कैसे करना है, इस समस्या का समाधान खोजना एक सराहनीय उपलब्धि होगी, क्योंकि यह उसी समय समस्या का समाधान होगा कि निष्क्रिय रहते हुए अन्य सामान कैसे किया जाए। एक आश्चर्यजनक उपलब्धि जो होगी, क्योंकि इसका मतलब होगा कि आप अपने कंप्यूटर को करने के लिए काम पाएंगे, जबकि इसके पास कोई भी नहीं है।

आप देखते हैं, यह वही हो रहा है: आपका कंप्यूटर केवल 99.99% समय बैठा है, कुछ भी नहीं कर रहा है। जब आप इसे करने के लिए कुछ देते हैं, तो यह जाता है और इसे करता है। यदि ऐसा करने में उसे I / O का इंतजार करना पड़ता है, तो वह वहां बैठती है और इंतजार करती है। यदि यह I / O करते समय कुछ और करना है, तो वह ऐसा करता है। लेकिन अगर इसे I / O के अलावा कुछ और नहीं करना है, तो उसे वहां बैठना होगा और I / O के पूरा होने का इंतजार करना होगा। SETI @ होम में नामांकन के अलावा, इसके आसपास काम करने का कोई तरीका नहीं है।

Comments

खैर 12.1% उदाहरण एक वेबसाइट से था और उदाहरण 8 कोर के साथ एक सर्वर से लिया गया था, विचार यह था कि लगभग एक ही कोर केवल उस ऑपरेशन के लिए आरक्षित था, निश्चित रूप से अन्य कोर कुछ भी करने के लिए स्वतंत्र थे और 8 कोर के साथ आप अच्छी तरह से बंद हैं, लेकिन क्या होगा यदि आपके पास केवल एक ही कोर है? : /

— आर्टुरस एम

@ArturasM या तो आपने गलत समझा है कि वेबसाइट क्या कह रही है, या वेबसाइट के लेखक ने कुछ गलत समझा है। केवल एक कोर वाला कंप्यूटर I / O के इंतजार में कम समय बिताएगा (क्योंकि सभी कार्य जो IO की प्रतीक्षा नहीं कर रहे हैं, जो कि अन्य कोर पर निष्पादित कर रहे हैं, जबकि एक कोर बेकार बैठता है, सभी को एकल पर निष्पादित करना होगा कोर)। I / O को निश्चित समय लगता है कि आप इसके लिए प्रतीक्षा करते हैं या नहीं - इसके लिए प्रतीक्षा करने का समय उस समय के साथ और कुछ नहीं होने का एक लक्षण है।

— रैंडम 832

Answer 4

ओएस (जब तक कि यह एक बहुत ही निम्न स्तर की एम्बेडेड प्रणाली या कुछ इसी तरह से विदेशी नहीं है) पहले से ही इस बात का ध्यान रखता है: यदि आपके आवेदन को I / O का इंतजार करना है, तो यह आमतौर पर उस I / O को ब्लॉक कर देगा और कुछ अन्य थ्रेड या एप्लिकेशन बन जाएगा सक्रिय। शेड्यूलर तय करता है कि कौन सा है।

यह केवल तभी है जब कोई अन्य धागा या एप्लिकेशन नहीं है जो चल सकता है कि आप वास्तव में प्रतीक्षा समय जमा कर रहे हैं। में लेख आपको उद्धृत (लिंक के लिए @manlio करने के लिए धन्यवाद), मामला है कि: यदि आप 12.1% बनाम 87.4% निष्क्रिय, जिसका मतलब है मैं / हे जबकि बाकी कुछ नहीं कर रहा है पूरा करने के लिए एक कोर इंतज़ार कर रहा है इंतज़ार कर रहे है बिलकुल। उस प्रणाली को कुछ करने के लिए, अधिमानतः कई somethings, और प्रतीक्षा प्रतिशत छोड़ देना चाहिए।

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

लिनक्स का उपयोग करते समय, यदि आप कुछ लंबे समय तक I / O कार्य कर रहे हैं, तो OS पूर्ण होने तक लगभग अनुपयोगी हो जाता है।

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

आप यह देखने के लिए टूल का उपयोग कर सकते iotopहैं कि कैसे I / O क्षमता प्रक्रियाओं के लिए आवंटित की गई है, और प्रक्रियाओं के ioniceलिए I / O प्राथमिकताएं निर्धारित करने के लिए। उदाहरण के लिए, डेस्कटॉप मशीन पर, आप idleशेड्यूलिंग क्लास के लिए सभी बल्क डेटा प्रोसेसिंग को वर्गीकृत कर सकते हैं , ताकि जिस क्षण कुछ इंटरेक्टिव एप्लिकेशन को I / O बैंडविड्थ की आवश्यकता हो, इंटरेक्टिव एप्लिकेशन पूरा होने तक बल्क प्रोसेसिंग निलंबित हो जाए।

Answer 5

यह आपके एप्लिकेशन कोड पर निर्भर करता है। मैं मान रहा हूं कि आपका कोड लिनक्स पर चल रहा है।

आप बहु- थ्रेडिंग (जैसे POSIX pthreads ) का उपयोग कर सकते हैं, जबकि कुछ IO- बाउंड थ्रेड IO कर रहे हैं (और इसके लिए प्रतीक्षा कर रहे हैं) कंप्यूट-बाउंड थ्रेड्स करने के लिए। आप अपने आवेदन को अंतर-प्रक्रिया संचार (IPC) के साथ संचार करने वाली कई प्रक्रियाओं को चला सकते हैं, पाइप (7) , फीफो (7) , सॉकेट (7) , यूनिक्स (7) , shm_overview (7) , sem_vview (7) देखें , mmap (2) , Eventfd (2) और उन्नत लिनक्स प्रोग्रामिंग आदि पढ़ें ...।

आप गैर-अवरोधक IO का उपयोग कर सकते हैं , उदाहरण के O_NOBLOCKलिए (2) आदि को खोलने के लिए पास ... आदि; फिर आपको मतदान (2) और / या SIGIO सिग्नल (7) का उपयोग करने की आवश्यकता होगी ... और पढ़ने (2) आदि EWOULDBLOCKसे त्रुटि को संभालना होगा ...

आप POSIX अतुल्यकालिक IO का उपयोग कर सकते हैं, aio (7) देखें

फ़ाइल एक्सेस के लिए, आप पेज कैश को संकेत दे सकते हैं , उदाहरण के लिए mmap (2) के बाद mmap (2) और posix_fadvise (2) के साथ ; लिनक्स विशिष्ट रीडहेड (2) भी देखें

लेकिन आप अंततः कुछ हार्डवेयर अड़चन (बस, रैम, आदि ...) तक पहुंच जाएंगे। आयनिस (1) भी देखें

Answer 6

मैं दूसरों की तुलना में अन्य दृष्टिकोणों को जोड़ता हूं, शायद विवादास्पद:

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

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

नोट: मैं यह नहीं कह रहा हूं कि विंडोज लिनक्स से बेहतर है, मैं कहता हूं कि उनके पास बस अलग-अलग समग्र दर्शन हैं, जो जटिल वातावरण में इन प्रणालियों के विभिन्न उच्च स्तर के व्यवहार / महसूस कर सकते हैं।

Comments

लिनक्स माउस लैग को शायद सिस्टम के सावधानीपूर्वक विन्यास (यानी भूखी प्रक्रियाओं पर niceऔर उपयोग करके ionice) से बचा जा सकता है या कम किया जा सकता है । और मैं लिनक्स का उपयोग करता हूं और लगभग कभी भी अनुभव नहीं किया है कि लिनक्स माउस लैग (मेरे कंप्यूटर को ओवरलोड करने के अलावा ...)

— बेसिल स्टैरनेवविच

BTW, लिनक्स ज्यादातर एक सर्वर ओएस है।

— बेसिल स्टारीनेवविच

मैं यह नोट करूंगा कि मैंने विंडोज 7 पर यूआई और माउस लैग का अनुभव किया है, यहां तक ​​कि ऐसे समय में भी जब टास्क मैनेजर और रिसोर्स मॉनिटर ने कम मेमोरी उपयोग और कम सीपीयू और डिस्क गतिविधि का संकेत दिया था।

— 8bittree