kernel का यह निर्णय है कि ready thread CPU पाएगा, और के लिए। चूँकि आमतौर पर cores से ज़्यादा runnable threads होते हैं, उन्हें multiplex करता है, और परस्पर टकराते लक्ष्यों — , , और — को संतुलित करने का प्रयास करता है, साथ ही से बचता है।
kernel का यह निर्णय है कि ready thread CPU पाएगा, और के लिए। चूँकि आमतौर पर cores से ज़्यादा runnable threads होते हैं, उन्हें multiplex करता है, और परस्पर टकराते लक्ष्यों — , , और — को संतुलित करने का प्रयास करता है, साथ ही से बचता है।
FCFS (first-come, first-served) → simple, but one long job blocks everyone (convoy effect)
SJF (shortest job first) → optimal avg wait, but needs to know job length; can starve long jobs
Round-robin (RR) → each job a fixed TIME SLICE (quantum), cycle through → fair, good latency
Priority → highest priority first → can STARVE low priority (fix: aging)
MLFQ (multi-level feedback) → several priority queues; jobs that use a full quantum sink,
interactive jobs that yield stay high → approximates SJF without knowing lengths
Round-robin मुख्य नियंत्रण-गाँठ को दर्शाता है — quantum:
quantum too SMALL → fair & responsive, but lots of context-switch overhead
quantum too LARGE → less overhead, but degrades toward FCFS (poor responsiveness)
Linux का लंबे समय तक default CFS (Completely Fair Scheduler) रहा: निश्चित slices के बजाय यह हर task के virtual runtime (vruntime) को track करता है और हमेशा उस thread को चलाता है जिसे अब तक सबसे कम CPU मिली है, जो उसके nice मान के अनुसार weighted होती है — यह "सबको उचित हिस्सा मिले" का लगभग-अनुमान है। यह vruntime द्वारा एक red-black tree को key करता है, इसलिए अगला task चुनना O(log n) है। (नए kernels EEVDF इस्तेमाल करते हैं, जो उसी fairness लक्ष्य के साथ एक परिष्कार है और साथ ही कसे हुए latency bounds देता है।)
Preemptive बनाम cooperative: आधुनिक OSes preemptive होते हैं — एक timer interrupt scheduler को CPU ज़बरदस्ती वापस लेने देता है, ताकि एक thread किसी core पर एकाधिकार न कर सके।
Scheduling सीधे उस latency और throughput को आकार देती है जो users महसूस करते हैं। Interviewers इसे यह देखने के लिए टटोलते हैं कि आप trade-offs समझते हैं या नहीं — एक interactive workload को छोटे quanta या priority boost क्यों चाहिए, priority scheduling को starvation रोकने के लिए aging क्यों चाहिए, और MLFQ/CFS job lengths को पहले से जाने बिना अच्छा interactive व्यवहार कैसे पाते हैं। यह nice, real-time priorities को tune करने, और किसी भूखे रह गए या lag करते service के निदान के पीछे का mental model भी है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें