लिनक्स पर अधिक धागे के साथ प्रक्रिया में एक थ्रेड के साथ प्रक्रिया की तुलना में अधिक सीपीयू समय होगा?

Question

क्या लिनक्स पर अधिक धागे वाली प्रक्रिया में एक थ्रेड के साथ प्रक्रिया की तुलना में अधिक सीपीयू समय होगा?

लिनक्स प्रक्रियाओं और धागे में कार्य संरचना द्वारा वर्णित किया गया है, और scheduling is based on tasks।

current->counter >>= 1; 
p->counter = current->counter; 

में:

जब एक नई प्रक्रिया बनाई गई है, do_fork() दोनों वर्तमान (पैरेंट) के काउंटर क्षेत्र और पी (बच्चे) निम्नलिखित तरीके से प्रक्रियाओं सेट: मैं भी this पाया दूसरे शब्दों में, माता-पिता को छोड़ी गई टिकों की संख्या दो हिस्सों में विभाजित है, एक माता पिता के लिए और एक बच्चे के लिए। यह उपयोगकर्ताओं को निम्नलिखित विधि का उपयोग करके असीमित मात्रा में CPU समय प्राप्त करने से रोकने के लिए किया जाता है: मूल प्रक्रिया एक बाल प्रक्रिया बनाती है जो एक ही कोड चलाती है और फिर खुद को मार देती है; सृजन दर को सही ढंग से समायोजित करके, बच्चे की प्रक्रिया हमेशा अपने माता-पिता की समाप्ति की मात्रा से पहले एक ताजा क्वांटम प्राप्त करेगी। यह प्रोग्रामिंग चाल काम नहीं करती है क्योंकि कर्नेल फोर्क इनाम नहीं देता है। इसी प्रकार, कोई उपयोगकर्ता शैल में बहुत सारी पृष्ठभूमि प्रक्रियाओं को शुरू करके या ग्राफिकल डेस्कटॉप पर बहुत सारी विंडो खोलकर प्रोसेसर का अनुचित हिस्सा नहीं लगा सकता है। आम तौर पर बोलते हुए, एक प्रक्रिया संसाधनों को हॉग नहीं कर सकती है (जब तक कि यह कई वंशजों को फोर्क करके स्वयं को वास्तविक समय नीति प्रदान करने के लिए विशेषाधिकार न हो)।

असल में मुझे कर्नेल स्रोतों में यह नहीं मिला, लेकिन शायद यह मेरी गलती है, शायद मैंने गलत कर्नेल संस्करण देखा है।

लेकिन बाद में क्या होता है, क्या प्रत्येक थ्रेड शेड्यूलिंग में एक अलग प्रक्रिया की तरह भाग लेता है? क्या दस धागे वाली प्रक्रिया एक थ्रेड के साथ प्रक्रिया की तुलना में दस गुना अधिक टिक प्राप्त करेगी? इस अर्थ में आईओ के बारे में क्या?

Answer 1

हां, अधिक धागे वाली प्रक्रिया को इसके प्रतिस्पर्धियों की तुलना में अधिक CPU समय मिलेगा। एक प्रसिद्ध मामला एक मेवेन संकलन होगा, मैवेन बहुत सारे सीपीयू-गहन धागे का उपयोग करता है, जो सिस्टम को हॉगिंग करता है।

लेकिन, वर्तमान लिनक्स शेड्यूलर केवल कार्य को ध्यान में नहीं लेता है, यह सीपीयू सीग्रुप पदानुक्रम में नियंत्रण समूहों को भी ध्यान में रखता है। इसलिए, CPU समय नियंत्रण समूहों के बीच विभाजित होता है, और फिर प्रत्येक नियंत्रण समूह में, CPU समय कार्यों के बीच विभाजित होता है।

2.6.38 के बाद से, लिनक्स स्वचालित रूप से अपने सत्र आईडी के आधार पर अलग-अलग cpu cgroups में डाल देता है। इसका मतलब है कि उदाहरण: कंसोल/gnome-terminal में अलग-अलग टैब अपना स्वयं का नियंत्रण समूह प्राप्त करते हैं। तो अब आपका मेवेन संकलन अच्छी तरह से अलग है, और अब सिस्टम को हॉग नहीं करता है। kernelnewbies और lwn.net पर विवरण देखें।

2.6.38 से अधिकतर सिस्टमों को हिट करने से पहले, लेनार्ट पोएटरिंग ने दिखाया कि इसे this LKML message पर शैल स्क्रिप्ट पर मैन्युअल रूप से कैसे किया जाए।

मैं वास्तव में एक प्रणाली है जहाँ मैं ग्रहण चलाने के लिए और Maven संकलित है, और पूर्व 2.6.38 से पूर्व 2.6.38 परिवर्तन + Lennart के cgroup बाध्यकारी (जो मैं अपने ग्रहण लांचर स्क्रिप्ट पर /etc/bashrcऔर पर डाल) बस सही था। मैवेन अब सिस्टम को हॉग नहीं करता है (आपको पता नहीं होगा कि अगर यह सीपीयू लोड मॉनीटर के लिए नहीं था तो मैवेन संकलन चल रहा था), और ग्रहण अब सिर्फ खुद को हॉग करता है, बाकी सिस्टम नहीं (मैं इसके लिए बसूंगा ग्रहण के साथ)। अब मुझे कर्नेल को बेहतर गंदी-पेज लिखने के साथ अपडेट करने की आवश्यकता है और यह सिस्टम काम करने के लिए एक हवा होगा।