ما الذي يغيّره فعلاً «Processor scheduling» على Windows بالنسبة إلى الخدمات في الخلفيّة وأطوال الـ quantum و P-cores / E-cores

ظلّ الناس يردّدون نسخاً من هذه القصّة على Windows لمدّة طويلة:

«إن أخرجتُ التطبيق من الـ foreground، يبدأ الصوت بالتشقّق».

«تغيير Processor scheduling إلى Background services جعله مستقرّاً».

هذا شائع بشكل خاصّ في سيناريوهات الصوت والفيديو والقياس والبثّ والمعالجة المستمرّة، حيث يكون العمل المستمرّ أهمّ من الـ UI نفسه.

لكنّ هذا الإعداد ليس مفتاح أداء سحريّاً.
هو لا يرفع تردّدات CPU مباشرةً، ولا يحوّل تطبيقاً عاديّاً إلى Windows service، ولا يثبّت العمل على P-cores. ما يغيّره أساساً هو كيفيّة توزيع زمن CPU بين عمل الـ foreground وعمل الخلفيّة.

يربط هذا المقال القطع معاً:

• ما الذي يغيّره الإعداد فعلاً
• كيف تختلف Programs و Background services
• لماذا قد يكون الإعداد مهمّاً للصوت أو خطوط الأنابيب المستمرّة
• كيف يتلاءم طول الـ quantum وتعزيزات الـ foreground في القصّة
• لماذا تضيف أنظمة P-core / E-core طبقة أخرى على هذا

1. النسخة المختصرة

الملخّص العمليّ هو هذا:

• يغيّر الإعداد توزيع زمن CPU، لا القوّة الخام للـ CPU.
• Programs يميل إلى تفضيل تطبيق الـ foreground بشكل أقوى.
• Background services يجعل التقسيم بين الـ foreground والخلفيّة أكثر تساوياً.
• يمكن أن يساعد ذلك أحمال العمل التي تحتوي عمليّة في الخلفيّة أو عمليّة جانبيّة لها مواعيد توقيت حقيقيّة.
• على أنظمة P-core / E-core الحديثة، يتأثّر وضع الأنوية بشكل أكثر مباشرةً بـ QoS وسياسة الطاقة و hybrid scheduling و Intel Thread Director.
• لذا فإنّ التغيير إلى Background services لا يعني «ينتقل عمل الخلفيّة إلى P-cores» أو «تذهب الخدمات إلى E-cores».
• إن كانت مشكلتك الحقيقيّة هي زمن DPC / ISR، أو توفير طاقة USB، أو سلوك driver، أو thermal throttling، أو EcoQoS، فلن يحلّ هذا الإعداد وحده ذلك.

في جملة واحدة:

هذا ليس إعداداً لتردّد CPU. هو إعداد لسياسة scheduling.

2. ما الذي يغيّره هذا الإعداد فعلاً

خيار Processor scheduling القديم هو أحد إعدادات سياسة الـ scheduling طويلة العمر في Windows.
تاريخيّاً، هو مرتبط بـ Win32PrioritySeparation، ولهذا ظلّ الإعداد موجوداً بشكل أو بآخر لمدّة طويلة.

الصورة الأساسيّة للـ scheduler هي:

• يختار Windows أعلى thread قابل للتشغيل بحسب الـ priority
• تتناوب الـ threads على نفس مستوى الـ priority
• هذا الدور محدود بـ quantum أو شريحة زمنيّة

flowchart LR
    ready["Runnable threads"] --> pick["Scheduler picks the highest-priority thread"]
    pick --> run["Run for one quantum"]
    run --> wait{"Other threads at the same priority waiting?"}
    wait -- yes --> switch["Context switch"]
    switch --> pick
    wait -- no --> run

ما يؤثّر فيه Processor scheduling بشكل أساسيّ هو:

• كيف يُوزَّع زمن الـ quantum
• إلى أيّ مدى يُفضَّل تطبيق الـ foreground

وتوضيح مهمّ:

اختيار Background services لا يحوّل تطبيقك إلى Windows service.
كلمة «services» في هذا الإعداد تتعلّق بسياسة توزيع CPU، لا بنوع التطبيق نفسه.

3. ما الذي يتغيّر بين Programs و Background services

طريقة عمليّة للتفكير في الفرق:

Windows للعميل (client) متحيّز طبيعيّاً نحو جعل تطبيق الـ foreground يبدو جيّداً.
لذلك يكون Programs الخيار الطبيعيّ للاستخدام العاديّ على سطح المكتب.

لكنّ التوازن يتغيّر في حالات مثل:

• خطوط أنابيب الصوت التي تملأ الـ buffers باستمرار
• عمل الالتقاط أو التحليل الذي يعمل في worker threads أو عمليّات مساعدة
• متصفّح أو IDE في الـ foreground بينما لا يزال خطّ أنابيب في الخلفيّة بحاجة إلى الالتزام بالمواعيد
• أحمال عمل شبيهة بالخدمات أو مقيمة (resident) حيث لا يكون الـ UI هو الحدث الرئيسيّ

في تلك الحالات، تقليل تحيّز الـ foreground يمكن أن يجعل النظام أكثر استقراراً بشكل عامّ.

4. لماذا يمكن أن يساعد في الصوت أو في عمل مستمرّ آخر

الصوت هو أسهل مثال للتفكير فيه.

معالجة الصوت لا تحتاج فقط إلى متوسّط جيّد.
هي بحاجة إلى أن يكون الـ buffer جاهزاً قبل الموعد مرّة بعد مرّة. حِمل CPU متوسّط منخفض يمكن أن يُنتج glitches مسموعة إن أخطأ الـ thread المهمّ اللحظة الخاطئة.

تخيّل وضعاً مثل هذا:

• متصفّح أو واجهة DAW أو تطبيق أماميّ آخر في الـ foreground
• thread في الخلفيّة أو عمليّة مساعدة تواصل تغذية buffers الصوت
• مسار الصوت ذلك لا يستخدم priority عالياً جدّاً، واستخدامه لـ MMCSS / QoS ليس مثاليّاً
• CPU مشغول باعتدال

مع Programs، يمكن لجانب الـ foreground الاحتفاظ بـ CPU لفترة أطول وبشكل أكثر اتّساقاً.
يمكن أن يُبقي ذلك مسار الصوت في الخلفيّة في حالة يبدو فيها المتوسّط جيّداً، لكنّ التوقيت لا يزال ينزلق بما يكفي ليحدث underrun.

مع Background services، قد يعود عمل الخلفيّة إلى CPU بشكل أكثر قابليّة للتنبّؤ، ممّا يقلّل المواعيد الفائتة.

لذا حين يساعد الإعداد، فإنّ ما يتحسّن ليس «السرعة الخام».
بل هو أقرب إلى:

• يقلّ تحيّز الـ foreground
• يحصل حِمل العمل في الخلفيّة على فرص scheduling أكثر إنصافاً
• تصبح المواعيد الفائتة أقلّ تكراراً

5. الآليّة: طول الـ quantum وتفضيل الـ foreground

هناك سبب مباشر يسمح بحدوث هذا.

5.1 الـ quanta الأطول تجعل الأقران ينتظرون أطول

إن كانت عدّة threads تتنافس على مستويات priority متشابهة، فإنّ thread يتلقّى زمن تنفيذ متواصلاً أطول يجعل الأخريات تنتظر بشكل طبيعيّ أطول.

حين يفضّل النظام الـ foreground بشكل أقوى، يستطيع جانب الـ foreground الاحتفاظ بالتنفيذ لفترة أطول.
يجعل ذلك من الأسهل لعمل الخلفيّة على priority مماثل أن يسمع «ليس الآن» في اللحظة الخاطئة بالضبط.

ولذلك يهمّ هذا أكثر شيء لأحمال العمل التي تحتاج إلى أن تعمل قليلاً، بانتظام، وفي الوقت المناسب:

• الصوت
• الفيديو
• أخذ العيّنات الدوريّ
• الـ polling
• المراقبة

5.2 يقوم Windows أصلاً بعدّة أنواع من تفضيل الـ foreground

ينتبه Windows إلى الـ foreground بطرق متعدّدة:

• تفضيل على مستوى العمليّة للـ foreground
• تفضيل للـ threads المرتبطة بالنافذة النشطة
• تعزيزات priority ديناميكيّة بعد إكمال I/O

لذا فإنّ مجرّد إخراج تطبيق من الـ foreground يغيّر صورة الـ scheduling العمليّة.
من الأسهل فهم Background services إن فكّرت فيه على أنّه يقلّل انحراف زمن CPU بين عمل الـ foreground وعمل الخلفيّة.

5.3 «يمنع CPU من التكاسل» صحيح بنصفه فقط

هذه العبارة منطقيّة بشكل حدسيّ لأنّ عمل الخلفيّة قد يُترك خلف الركب فعلاً بشكل أقلّ.
لكن من الناحية التقنيّة، الإعداد ليس بشكل أساسيّ حول:

• حالات الـ idle
• تردّد CPU
• turbo boost
• core parking
• تثبيت P-core

هو في الأساس حول مَن يعمل ومتى وإلى أيّ مدى.

6. ما الذي يتغيّر على معالجات P-core / E-core

هنا يصبح الالتباس أكثر شيوعاً بكثير.

اختيار Background services لا يعني أنّ Windows يتّخذ فجأةً قراراً بسيطاً مثل:

• عمل الخلفيّة -> E-cores
• عمل الـ foreground -> P-cores

على Windows الحديث، خاصّة Windows 11 على CPUs هجينة، القصّة أكثر طبقيّةً بكثير.

6.1 نظامان يبدو اسمهما متشابهاً ليسا الشيء نفسه

هناك طبقتان مختلفتان هنا:

1. خيار Processor scheduling القديم مع Background services
   • توزيع زمن CPU الكلاسيكيّ بين الـ foreground والخلفيّة
   • منطقة الـ quantum وتعزيز الـ foreground
2. فئات QoS الحديثة مثل Utility أو Low أو Eco
   • تتدخّل بشكل أكثر مباشرة في نيّة الطاقة / الأداء
   • أكثر صلة بكثير بوضع P-core / E-core

هذان ليسا الآليّة نفسها.

6.2 على Windows 11، تهمّ QoS والرؤية كثيراً

على Windows الحديث، الـ priority ليس الصورة الكاملة. الـ QoS مهمّ أيضاً، وعلى CPUs غير المتجانسة يهمّ ذلك بشكل مباشر في تحديد أيّ فئة من الأنوية يفضّلها الـ thread.

بشكل عامّ، يتصرّف Windows 11 بشيء كهذا:

من أهمّ الآثار العمليّة أنّ تصغير تطبيق يمكن أن يغيّر سلوكه في الـ scheduling بطرق لا علاقة لها كثيراً بمفتاح Processor scheduling القديم.

لذا على لابتوب هجين، من الطبيعيّ جدّاً رؤية سلسلة مثل:

• يخرج التطبيق من الـ foreground
• ثمّ يُصغَّر
• ينخفض QoS
• يزيد التحيّز نحو efficient core
• يسوء التوقيت

تلك طبقة مختلفة عن خيار Background services القديم.

6.3 يضيف Thread Director و hybrid scheduling طبقة أخرى

على Intel CPUs الهجينة، يوفّر Intel Thread Director hints للـ scheduling لـ OS.
يستخدم Windows 11 تلك الـ hints بشكل أكثر فعاليّة من إصدارات Windows الأقدم.

يمتلك Windows أيضاً إعدادات سياسة scheduling غير متجانسة مثل:

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

تعمل هذه معاً مع QoS وإدارة طاقة المعالج لتشكيل أين يستقرّ العمل وكيف يتوسّع.

الصورة الكاملة أقرب إلى هذا:

flowchart TD
    t["Thread"] --> p["Priority / dynamic priority"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibility / audible / input state"]
    t --> h["Hybrid scheduling policy<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Intel Thread Director hints<br/>Windows 11 on Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["P-cores / E-cores and frequency behavior"]

خيار Processor scheduling القديم لا يزال مهمّاً.
لكنّه لم يعد يفسّر القصّة بأكملها بمفرده.

7. متى يساعد ذلك ومتى لا يساعد

أسرع طريقة للحفاظ على وضوح الذهن هي فصل الحالات التي يكون فيها هذا الإعداد خيطاً جيّداً عن الحالات التي ليس كذلك.

7.1 الحالات التي يمكن أن يساعد فيها فعلاً

هو رافعة معقولة عندما:

• ينقل الـ focus بعيداً عن التطبيق يجعل خطّ الأنابيب في الخلفيّة فقط غير مستقرّ
• استخدام CPU الإجماليّ ليس مشبعاً، لكنّ المواعيد الدوريّة لا تزال تنزلق
• العمل الحرج يعيش في تطبيق legacy أو عمليّة مساعدة أو worker thread لا يستخدم MMCSS / QoS بشكل جيّد
• الأولويّة الحقيقيّة هي استقرار الخلفيّة، لا شعور UI الـ foreground

في تلك الحالات، قد تكون المشكلة فعلاً:

محاباة الـ foreground قويّة جدّاً بالنسبة لحمل العمل الذي يهمّك.

7.2 الحالات التي يكون فيها ضعيفاً أو ببساطة الطبقة الخاطئة

هذا الإعداد ليس الإجابة الكاملة إن كانت المشكلة الحقيقيّة:

• زمن DPC / ISR عالٍ
• مشاكل في USB controller أو في audio driver
• USB selective suspend أو إدارة طاقة الجهاز
• thermal throttling
• تأثيرات battery saver أو power throttling أو EcoQoS
• buffer ببساطة صغير جدّاً
• تطبيق يستخدم أصلاً MMCSS / Deadline بشكل صحيح، مع المشكلة الحقيقيّة في مكان آخر

على أنظمة Windows 11 الهجينة، إن كان السلوك يتغيّر بشكل أساسيّ حين يُصغَّر التطبيق أو يُخفى أو يُفصل عن AC، فإنّ QoS وسياسة الطاقة في الغالب مكان أفضل للنظر إليه أوّلاً.

8. طريقة عمليّة لتقييمه

إن أردت اختبار هذا بترتيب منطقيّ، فإنّ التسلسل التالي يعمل بشكل جيّد:

1. ثبِّت الظروف
   • AC أو battery
   • وضع الطاقة
   • حجم الـ buffer
   • حالة foreground / visible / minimized
2. قارن Programs و Background services تحت الظروف نفسها
   • سجِّل الانقطاعات والـ glitches أو أخطاء التوقيت بدلاً من الاعتماد على الشعور وحده
3. على Windows 11 ذي CPUs الهجينة، افحص جانب QoS أيضاً
   • هل يسوء فقط حين يُصغَّر؟
   • هل يغيّر التشغيل المسموع السلوك؟
   • هل يحدث فقط على البطّاريّة؟
4. بالنسبة للصوت أو الفيديو، افحص استخدام MMCSS
   • هل يخبر الـ thread المهمّ Windows فعلاً بأنّ سلوك الـ deadline مهمّ؟
5. إن لم يزل الأمر غير واضح، انتقل إلى التحقيق في DPC / ISR / USB / driver
   • عند تلك النقطة، قد لا تعود القصّة بشكل أساسيّ حول سياسة الـ scheduler

في الممارسة، متوسّط استخدام CPU في الغالب أقلّ أهمّيّة من سؤال واحد:

هل وصل العمل إلى موعده؟

ذلك هو الجوهر الحقيقيّ لهذه الحالات.

9. الخلاصة

إن ضغطت الموضوع بأكمله في ملخّص واحد، فإنّه يبدو هكذا:

• يغيّر الإعداد كيف يُقسم زمن CPU بين عمل الـ foreground وعمل الخلفيّة
• Programs يميل إلى جعل تطبيق الـ foreground يشعر بشكل أفضل
• Background services يمكن أن يساعد عمل الخلفيّة المستمرّ على تجنّب الضغط
• لذلك يمكن أن يساعد في الصوت والفيديو والالتقاط والمراقبة وأحمال العمل المقيمة
• لكن على CPUs ذات P-core / E-core، يتأثّر وضع الأنوية الفعليّ بقوّة أيضاً بـ QoS وسياسة الطاقة و hybrid scheduling و Thread Director
• لذا على أنظمة Windows الحاليّة، يكون هذا الإعداد ذا صلة في الغالب، لكنّه نادراً ما يكون التفسير الكامل بمفرده

باختصار:

هذا مقبض لتوزيع العمل، وليس مقبضاً للقوّة.

هو منطقيّ حين تكون المشكلة الحقيقيّة محاباة الـ foreground.
وهو أقلّ منطقيّةً بكثير حين تكون المشكلة الحقيقيّة في QoS أو في الـ drivers أو في سلوك الطاقة أو في زمن المقاطعات.

10. مراجع

• Sawady: バックグラウンドサービスを優先する設定（CPUをサボらせない）
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: Priority Boosts
• Microsoft Learn: Window Features
• Microsoft Learn: Quality of Service
• Microsoft Learn: SetThreadInformation function
• Microsoft Learn: SetProcessInformation function
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: Processor power management options overview
• Microsoft Learn: SchedulingPolicy
• Microsoft Learn: ShortSchedulingPolicy
• Microsoft Learn: ShortThreadRuntimeThreshold
• Intel Support: Is Windows 10 Task Scheduler Optimized for 12th Generation Intel Core Processors?
• Intel White Paper: Intel performance hybrid architecture & software optimizations, Part Two