إعداد Processor scheduling في Windows: خدمات الخلفية وأنوية P/E

«إذا أخرجتُ التطبيق من الواجهة، يبدأ الصوت بالطقطقة» «نقلتُ Processor scheduling إلى Background services فاستقرّ»

هذه الحكاية تظهر على Windows منذ زمن. وهي مزعجة خصوصاً في الصوت والفيديو والقياس والبثّ والمعالجة المقيمة: مواضع يكون فيها العمل المستمر أهمّ من الواجهة.

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

flowchart TB
    accTitle: ما الذي يغيّره هذا الإعداد
    accDescr: مخطّط يبيّن أن إعداد Processor scheduling ليس إعداداً يرفع التردّد ولا يحوّل التطبيق إلى خدمة ولا يثبّت النواة، وأن ما يتغيّر هو توزيع زمن CPU بين تطبيق الواجهة وعمل الخلفية.
    st1["إعداد Processor scheduling"] -.->|"هذه لا تتغيّر"| notx["التردّد، التحويل إلى خدمة، تثبيت النواة"]
    st1 -->|"ما يتغيّر"| shr1["توزيع زمن CPU بين الواجهة والخلفية"]

الشكل 1: ليس مفتاح تسريع، بل إعداد يبدّل طريقة توزيع زمن CPU.

تربط هذه المقالة ما يتغيّر بين Programs و Background services بأساسيات scheduler في Windows، وبـ quantum (الشريحة الزمنية)، وبتفضيل foreground، وبسلوك معالج يحمل أنوية P-core / E-core.

1. الخلاصة أوّلاً

النقاط الأساسية فقط.

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

بجملة واحدة: هذا الإعداد ليس إعداد تردّد CPU، بل إعداد لقاعدة الانتظار في الطابور.

flowchart TB
    accTitle: ما ينفع وما لا ينفع بإيجاز
    accDescr: مخطّط يبيّن أن جانب Background services قد ينفع عندما يكون موعد العمل المستمر في الخلفية مهمّاً، بينما اختيار P-core أو E-core تحدّده آليات أخرى مثل QoS وسياسة الطاقة.
    bgss1["جانب Background services"] -->|"قد ينفع"| dl1["موعد العمل المستمر في الخلفية"]
    bgss1 -.->|"ما يقرّر ذلك آلية أخرى"| core1["اختيار P-core / E-core"]
    core1 --> qos1["QoS وسياسة الطاقة وhybrid scheduling"]

الشكل 2: قد ينفع للموعد النهائي، أما اختيار النواة فتقرّره آليات خارج هذا الإعداد.

1.1 مصطلحات يحسن تثبيتها مسبقاً

تظهر في صدر المقال مصطلحات لا تتّضح حقيقتها إلا حوالي الفصل 6. نثبّتها هنا.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 18، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

الصورة الأساسية لاستخدام Windows لـ CPU هي هذه.

• يختار scheduler أعلى الخيوط القابلة للتشغيل أولويّة.
• إن تساوت الأولويّة، يجريها بالتناوب لمدّة ثابتة.
• هذه «المدّة الثابتة» هي quantum (الشريحة الزمنية).

flowchart LR
    ready["خيوط قابلة للتشغيل"] --> pick["scheduler يختار أعلى خيط أولويّة"]
    pick --> run["تشغيل لمدّة quantum واحد"]
    run --> wait{"هل تنتظر خيوط أخرى بنفس الأولويّة؟"}
    wait -- yes --> switch["تبديل سياق"]
    switch --> pick
    wait -- no --> run

الشكل 3: يختار scheduler أعلى خيط أولويّة ويشغّله بالتناوب quantum واحداً في كل مرّة.

ما يلمسه Processor scheduling أساساً هو توزيع هذا quantum ومدى تفضيل foreground.

foreground هنا هو التطبيق الذي يلمسه المستخدم الآن. أما العمل الذي خرج إلى الخلف، أو عامل في عملية أخرى، أو خدمة Windows، أو عملية مساعدة، أو معالجة مقيمة، فتميل إلى جانب background.

المهم: اختيار Background services لا يحوّل تطبيقك إلى خدمة Windows. ما يتغيّر ليس نوعاً اسمه خدمة، بل قاعدة توزيع CPU بين foreground وbackground. الاسم مضلّل جدّاً.

flowchart TB
    accTitle: التباس اسم Background services
    accDescr: مخطّط يبيّن أن اختيار Background services لا يحوّل تطبيقك إلى خدمة Windows، وأن ما يتغيّر هو قاعدة توزيع CPU بين foreground وbackground فقط.
    sel2["اختيار Background services"] -.->|"هذا لا يحدث"| svcx["يصبح التطبيق خدمة Windows"]
    sel2 -->|"ما يتغيّر"| rule1["قاعدة توزيع CPU بين الواجهة والخلفية"]

الشكل 4: رغم الاسم، ما يتغيّر ليس نوع العملية بل قاعدة التوزيع.

2.1 كيف تصل إلى شاشة الإعداد

هذا الإعداد مدفون في لوحة التحكّم. هناك مساران.

• من Win + R شغّل SystemPropertiesPerformance.exe فيفتح «خيارات الأداء» مباشرة. في تبويب «إعدادات متقدّمة» تجد Processor scheduling.
• إن تتبّعت يدوياً: «خصائص النظام» > تبويب «إعدادات متقدّمة» > «إعداد» تحت «الأداء» > تبويب «إعدادات متقدّمة». «خصائص النظام» نفسها تُفتح بـ sysdm.cpl.

نتيجة الاختيار تُكتب في قيمة السجل التالية.

إن أردت القيمة الحالية فقط، اقرأها بـ PowerShell. احتفظ بالقيمة قبل التغيير حتى تستطيع الرجوع.

flowchart TB
    accTitle: علاقة اختيار الواجهة بالسجل
    accDescr: مخطّط يبيّن أن نتيجة الاختيار في واجهة خيارات الأداء تُكتب في قيمة السجل Win32PrioritySeparation، وأن القيمة الحالية تُقرأ بـ PowerShell، لذلك يُحتفَظ بها قبل التغيير.
    uix2["اختيار في الواجهة"] --> regw1["يُكتب في Win32PrioritySeparation"]
    regw1 --> pr1["تُقرأ القيمة الحالية بـ PowerShell"]
    pr1 -.-> keep2["احتفظ بالقيمة ثم غيّر"]

الشكل 5: حقيقة اختيار الواجهة قيمة سجل، فاحتفظ بالقيمة الحالية قبل أن تلمسها.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl' -Name 'Win32PrioritySeparation'

2.2 إصدارات Windows المعنيّة ومعنى القيمة

Processor scheduling في «خيارات الأداء» موجود على عميل Windows 10 / Windows 11 وعلى Windows Server أيضاً. غير أن القيمة نفسها تُفسَّر تفسيراً مختلفاً بين العميل والخادم، وهذا ما يصعّب فهم الإعداد.

شرح Microsoft للسجل يقول إن Win32PrioritySeparation قناع بتّات من 6 بتات مقسومة إلى ثلاث مجموعات من بتّين (AABBCC).

• البتّان العلويان: هل quantum أطول أم أقصر
• البتّان الأوسطان: هل quantum متغيّر أم ثابت
• البتّان السفليان: كم مرّة يُفضَّل foreground على background (لا يعملان إلا عند التغيّر)

ثم يقال إن اختيار الواجهة يكتب القيم التالية (كانت واجهة ذلك العهد Applications و Background services، وتقابل اليوم Programs و Background services).

إن نزلنا خطوة بالأرقام، تقول مقالة Microsoft إن quantum عند 0x26 هو 18 للواجهة و6 للخلفية، وعند 0x18 كلاهما 36. الوحدة ثلث clock tick، فإذا حوّلناها إلى tick صارت 6 tick للواجهة / 2 tick للخلفية مقابل 12 tick لكليهما. تذكر المقالة نفسها مثالاً كان فيه clock tick على آلة x86 متعدّدة المعالجات 15.625 ميلي ثانية، فيصير الفرق «الواجهة تجري حتى نحو 94 ميلي ثانية متّصلة» مقابل «الواجهة والخلفية تجريان نحو 188 ميلي ثانية لكل منهما».

أي أن جانب Background services توزيع يجري فيه الدور الواحد أطول، لكنّه لا يحابي الواجهة وحدها. يصعب أن يبقى عمل الخلفية في حالة «لا يأتي دوره».

flowchart TB
    accTitle: توزيع quantum في الإعدادين
    accDescr: مخطّط يبيّن أن إعداد Programs يعطي الواجهة 6 tick والخلفية 2 tick فتطول الواجهة، وأن إعداد Background services يعطي كليهما 12 tick، فيطول الدور الواحد دون محاباة الواجهة وحدها.
    pg1["إعداد Programs"] --> fg6["الواجهة 6 tick والخلفية 2 tick"]
    bg2["إعداد Background services"] --> eq12["الواجهة والخلفية 12 tick"]
    eq12 --> nofam1["يصعب أن لا يأتي دور الخلفية"]

الشكل 6: أحد الجانبين يطيل الواجهة، والآخر يوزّع وقتاً أطول بالتساوي.

تفسير القيمة الافتراضية نفسه يختلف بين أنظمة التشغيل. في شرح Microsoft لـ Win32_OperatingSystem، عميل Windows quantum متغيّر الطول وأطول لتطبيق الواجهة، وWindows Server quantum ثابت الطول افتراضياً. شرح السجل يقول أيضاً إن القيمة الافتراضية نفسها 0x2 تعني على العميل «قصير، متغيّر، الواجهة ثلاثة أضعاف»، وعلى الخادم «طويل، ثابت، متساوٍ». لهذا يميل الخادم من الأصل إلى ما يعادل Background services.

flowchart TB
    accTitle: القيمة الافتراضية نفسها تُفسَّر مختلفاً بين العميل والخادم
    accDescr: مخطّط يبيّن أن القيمة الافتراضية نفسها تُفسَّر على عميل Windows قصيراً متغيّراً بتفضيل الواجهة ثلاثة أضعاف، وعلى Windows Server طويلاً ثابتاً متساوياً، لذلك يميل الخادم من الأصل إلى ما يعادل Background services.
    dv1["القيمة الافتراضية نفسها"] -->|"العميل"| cl2["قصير، متغيّر، الواجهة 3 أضعاف"]
    dv1 -->|"الخادم"| sv4["طويل، ثابت، متساوٍ"]
    sv4 -.-> lean1["من الأصل يعادل Background services"]

الشكل 7: ليس القيمة نفسها بل نظام التشغيل هو من يفرّق تفسير الافتراضي.

الأرقام المحدّدة هنا مبنيّة على وثائق ومقالات Microsoft من جيل Windows 2000 / XP. تطابق قيمة السجل مع الواجهة ما زال كما هو، لكن معاملة quantum الفعلية قد تختلف حسب إصدار نظام التشغيل، فاقرأ الأرقام على أنها مقياس لمرتبة الحجم لا أكثر.

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

الفرق أوضح في جدول.

عميل Windows موجّه أساساً لجعل تطبيق الواجهة مريحاً. لذلك في تشغيل سطح المكتب العادي يكون Programs طبيعياً.

غير أن المشهد يتغيّر في حالات.

• معالجة صوت تملأ المخزن بلا انقطاع في الخلف
• واجهة خفيفة، والتقاط أو تحليل يجري في خيط أو عملية أخرى باستمرار
• متصفّح أو IDE في الواجهة، ومع ذلك تريد حفظ مواعيد العمل في الخلف
• حمل أقرب إلى خادم أو خدمة أو إقامة دائمة

هنا يكون استقرار الخلفية في استعادة CPU أفضل من تفضيل الواجهة بقوّة. بهذا المعنى قد يكون Background services منطقياً.

flowchart TB
    accTitle: أي توزيع يناسب
    accDescr: مخطّط يبيّن أن التشغيل التفاعلي لسطح المكتب يناسبه إعداد Programs بتفضيل الواجهة، وأن الأحمال التي يهمّ فيها موعد العمل المستمر في الخلف يناسبها إعداد Background services لأن الخلفية تستعيد CPU بسهولة أكبر.
    wl1["طبيعة الحمل"] -->|"تشغيل تفاعلي"| pgn1["Programs طبيعي"]
    wl1 -->|"موعد الخلفية مهم"| bgn1["Background services مرشّح"]
    bgn1 --> back2["الخلفية تستعيد CPU بسهولة أكبر"]

الشكل 8: الاختيار ينقلب بحسب ما تريد حفظه: خفّة الواجهة أم موعد الخلفية.

4. لماذا قد ينفع في الصوت والمعالجة المستمرة

طقطقة الصوت وdropout مثال واضح.

معالجة الصوت لا يكفي أن تكون «سريعة في المتوسّط». كل بضعة ميلي ثانية، أو في وحدة أقصر، يجب ملء المخزن قبل التوقيت المطلوب. حتى إن كان متوسّط استخدام CPU منخفضاً، يكفي أن لا يجري الخيط في تلك اللحظة حتى ينقطع الصوت.

سيناريو ملموس:

• في الواجهة متصفّح أو واجهة DAW أو تطبيق آخر
• في الخلف خيط صوت يدور بفترة ثابتة ويمدّ المخزن
• خيط الصوت ليس عالي الأولويّة أكثر ممّا ينبغي، وMMCSS وQoS غير مستخدمين بما يكفي
• CPU مزدحم إلى حدّ معقول

عندها تحت Programs يسهل أن تجري الواجهة أطول، فيتأخّر صوت الخلفية «رغم أن المتوسّط سليم، في تلك اللحظة فقط». إن تكرّر هذا صار underrun، ثم طقطقة.

إن نقلت إلى Background services، قد تستعيد المعالجة المستمرة في الخلف CPU بسهولة أكبر، فيصعب فوات الموعد.

أي أن ما يحدث عندما ينفع الإعداد ليس أن «CPU صار أسرع»، بل:

• يضعف تفضيل تطبيق الواجهة قليلاً
• تتحسّن مرّات وتوقيتات مقاطعة الخلفية
• فتنخفض حالات فوات deadline

flowchart TB
    accTitle: مسار انخفاض طقطقة الصوت
    accDescr: مخطّط يبيّن أن إعداد Programs يطيل الواجهة فيتأخّر صوت الخلفية في تلك اللحظة فيحدث underrun، وأن النقل إلى Background services يضعف تفضيل الواجهة فيسهل على الخلفية المقاطعة فتنخفض حالات فوات الموعد.
    fgl1["الواجهة تجري أطول"] --> late1["معالجة الصوت تتأخّر في تلك اللحظة"]
    late1 --> ur1["underrun وطقطقة"]
    even2["التوزيع يُمال إلى التساوي"] --> take1["الخلفية تقاطع بسهولة أكبر"]
    take1 --> less1["فوات الموعد ينخفض"]

الشكل 9: عندما ينفع الإعداد، ليس CPU أسرع، بل عمل الخلفية يلحق موعده.

5. المبدأ: quantum وتفضيل foreground

إن نزلنا طبقة، مسار التأثير كالتالي.

5.1 quantum أطول يجعل الندّ بنفس الأولويّة ينتظر أكثر

عندما تتنافس عدّة خيوط في نطاق الأولويّة نفسه، كلّما طال quantum أحدها طال انتظار الآخرين.

في إعداد يفضّل تطبيق الواجهة، يسهل أن يجري جانب foreground متّصلاً أطول. عندها يأكل جانب background بنفس الأولويّة تقريباً مزيداً من «ليس الآن».

في الصوت والفيديو والقياس الدوري والاستعلام والمراقبة — أي عمل يريد أن يجري بانتظام ولو قليلاً — يظهر هذا الفرق.

flowchart TB
    accTitle: quantum طويل يُنتظر عنده الندّ
    accDescr: مخطّط يبيّن أنه عندما تتنافس خيوط في نطاق الأولويّة نفسه، فإن منح أحدها quantum أطول يجعل الآخرين ينتظرون أكثر، وأن الفرق يظهر في العمل الذي يريد الجري بانتظام ولو قليلاً.
    comp1["تنافس في نطاق الأولويّة نفسه"] --> long1["أحدها يأخذ quantum أطول"]
    long1 --> wt2["الخيوط الأخرى تنتظر أكثر"]
    wt2 -.-> perio1["الفرق أوضح كلّما أراد العمل الجري بانتظام"]

الشكل 10: طول quantum يرتدّ مباشرة زمن انتظار على الندّ المنافس.

5.2 Windows يراعي foreground بأشكال عدّة

Windows يراعي foreground أصلاً بقوّة. أبرز الأشكال:

• تفضيل العملية التي صارت في الواجهة
• تفضيل خيط النافذة التي استقبلت إدخالاً
• رفع أولويّة ديناميكي بعد اكتمال I/O

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

flowchart TB
    accTitle: أشكال مراعاة Windows لـ foreground
    accDescr: مخطّط يبيّن أن Windows يراعي foreground بأشكال عدّة منها تفضيل العملية في الواجهة، وتفضيل خيط نافذة الإدخال، والرفع الديناميكي بعد اكتمال I/O، لذلك تتغيّر المعاملة بمجرّد إخراج التطبيق من الواجهة.
    fgc1["تفضيل عملية الواجهة"] --> chg2["إخراج من الواجهة وحده يغيّر المعاملة"]
    fgc2["تفضيل خيط نافذة الإدخال"] --> chg2
    fgc3["رفع ديناميكي بعد اكتمال I/O"] --> chg2
    chg2 -.-> shrink1["هذا الإعداد يصغّر انحراف التوزيع"]

الشكل 11: تفضيل الواجهة تراكب آليات عدّة، وهذا الإعداد يؤثّر في انحراف التوزيع منها.

5.3 «لا تدع CPU يتكاسل» نصف صحيح ونصف منحرف

عبارة «لا تدع CPU يتكاسل» مفهومة حسّاً. بمعنى أن عمل الخلفية يصعب تأجيله، هذا صحيح.

لكنّ الأدق تقنياً أن ما يتغيّر فعلاً ليس تحكّم خمول CPU أو التردّد نفسه، بل بأي ترتيب وإلى أي طول تشغّل الخيوط.

لذلك هذا الإعداد:

• ليس إعداداً يرفع turbo boost
• ليس إعداداً يقطع C-state
• ليس إعداداً يغيّر core parking مباشرة
• ليس إعداداً يثبّت على P-core

flowchart TB
    accTitle: المعنى الدقيق لـ «لا تدع يتكاسل»
    accDescr: مخطّط يبيّن أن ما يتغيّر بهذا الإعداد ليس تحكّم خمول CPU ولا التردّد، بل ترتيب تشغيل الخيوط وطولها، وأنه ليس إعداد turbo أو C-state أو core parking أو تثبيت على P-core.
    sabo1["إحساس «لا تدع CPU يتكاسل»"] -->|"ما يتغيّر فعلاً"| ord2["ترتيب التشغيل وطوله"]
    sabo1 -.->|"ما لا يتغيّر"| pw2["turbo وC-state وcore parking وتثبيت النواة"]

الشكل 12: حقيقة «لا تدع يتكاسل» ليست تحكّم الطاقة، بل تغيير الترتيب وزمن الحيازة.

6. كيف يؤثّر على معالج P-core / E-core

هنا أكثر موضع يُساء فهمه.

اختيار Background services لا يعني أن Windows يقرّر ببساطة «خلفية إذن E-core» أو «واجهة إذن P-core». على Windows الحديث، وخصوصاً hybrid CPU في Windows 11، اختيار P-core / E-core متعدّد الطبقات أكثر من ذلك.

6.1 اسمان متشابهان وشيئان مختلفان

هناك شيئان متشابهان اسماً ومختلفان حقيقة.

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

الاثنان ليسا الشيء نفسه.

flowchart TB
    accTitle: اسمان متشابهان وشيئان مختلفان
    accDescr: مخطّط يبيّن أن إعداد Processor scheduling إعداد واجهة قديمة يؤثّر في سلالة quantum وتفضيل foreground، وأن QoS تصنيف طاقة/أداء حديث يؤثّر في اختيار النواة وتحكّم التردّد، وأنهما ليسا الشيء نفسه.
    old2["إعداد Processor scheduling"] --> qt1["سلالة quantum وتفضيل foreground"]
    newq1["تصنيف QoS"] --> cs2["سلالة اختيار النواة وتحكّم التردّد"]
    old2 -.->|"ليسا الشيء نفسه"| newq1

الشكل 13: الجو الاسمي متقارب، لكن الطبقة التي تؤثّر مختلفة تماماً.

6.2 QoS والظهور في Windows 11

على Windows الحديث يعمل QoS إلى جانب الأولويّة. خصوصاً على معالج غير متجانس، أي تكوين P-core / E-core، يؤثّر QoS في أي نوع من النوى يُفضَّل.

التصنيف التقريبي في Windows 11 كالتالي.

هذا الجدول إعادة تجميع لجدولين في «Quality of Service» على Microsoft Learn: قائمة مستويات QoS (High / Medium / Low / Utility / Eco / Media / Deadline) وتصنيف QoS (من حالة ظهور النافذة إلى QoS). ليس تصنيفاً من رصد ميداني. الوثيقة نفسها تنصّ أيضاً على أن العملية المحكوم بأنها تشغّل صوتاً تُعامل High، وأن الخيط الذي لا يندرج في أي ممّا سبق يُسند تلقائياً بتحليل إرشادي يشمل الأولويّة.

هناك وصف أهم لمن يقيس. إن انقطع إدخال المستخدم مدّة على البطارية، قد يُخفض QoS تطبيق الواجهة إلى Medium. تحذّر الوثيقة من تعطيل هذه الوظيفة عند قياس الأداء على البطارية، وتشرح التعطيل بوضع 1 في DisableUserPresenceQos (REG_DWORD) تحت HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling. إن ظهر «بطيء على البطارية فقط» في اختبار آلي بلا إدخال، فابدأ بالشك هنا.

المهم: التصغير وحده قد يغيّر QoS. أي أن على حاسوب محمول بمعالج hybrid يحدث عادة:

• أخرجت التطبيق من الواجهة
• ثم صغّرته
• فانخفض QoS
• فصار أقرب إلى efficient core
• فتدهور الإحساس أو الموعد

flowchart TB
    accTitle: سلسلة من التصغير إلى تدهور الموعد
    accDescr: مخطّط يبيّن أنه على حاسوب محمول بمعالج hybrid يكفي إخراج التطبيق من الواجهة وتصغيره لينخفض QoS، فيوضع على البطارية أقرب إلى efficient core، فيتدهور الإحساس أو الموعد.
    mn2["إخراج من الواجهة ثم تصغير"] --> qd1["ينخفض QoS"]
    qd1 -->|"خصوصاً على البطارية"| ec1["يوضع أقرب إلى efficient core"]
    ec1 --> ws1["يتدهور الإحساس أو الموعد"]

الشكل 14: عملية التصغير وحدها قد تصل السلسلة حتى وضع النواة.

6.3 Thread Director وhybrid scheduling

على معالج Intel hybrid من الجيل 12 فما بعده، يقدّم Intel Thread Director تلميحات لنظام التشغيل. يستخدم Windows 11 ذلك ليقرّر تخصيص P-core / E-core بذكاء أكبر.

إضافة إلى ذلك، لدى Windows سياسات heterogeneous scheduling.

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

إن تُركت على Automatic، يقرّر نظام التشغيل بالنظر إلى QoS وتكوين النظام. وخلف ذلك يعمل أيضاً محرّك core parking ومحرّك حالة الأداء في إدارة طاقة المعالج.

الصورة الكلّية تقريباً كالتالي.

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<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["تلميحات Intel Thread Director<br/>Windows 11 على Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["تُحدَّد نواة P / E والتردّد"]

الشكل 15: تلتقي الأولويّة وQoS وحالة الظهور وسياسة الجدولة وتلميحات Thread Director فتُحدَّد النواة والتردّد.

7. متى ينفع ومتى لا ينفع

عملياً أسرع أن تفصل الحالات التي يسهل أن ينفع فيها عن الحالات التي هي مشكلة أخرى.

7.1 حالات يسهل أن ينفع فيها

هنا قد يكون Background services علاجاً في محلّه.

• نقل البؤرة إلى تطبيق الواجهة يجعل العمل المستمر في الخلف وحده غير مستقر
• استخدام CPU غير مشبع، ومع ذلك يفوت موعد المعالجة الدورية فقط
• المعالجة الحرجة في تطبيق قديم / عملية مساعدة / خيط عامل، واستخدام MMCSS أو QoS غير كافٍ
• الخدمة أو المعالجة المقيمة هي البطلة، واستقرار الخلف أهمّ من خفّة الواجهة

7.2 حالات ينفع فيها قليلاً، أو هي مشكلة أخرى

بالمقابل، هناك مشاكل لا يكفي هذا الإعداد وحده لها.

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

خصوصاً على حاسوب محمول Windows 11 + hybrid CPU، تغيّر الظهور وQoS يؤثّر كثيراً. إن تباطأ بعد التصغير، أو ساء على البطارية فقط، فالأقرب أن تشكّ في QoS / الطاقة قبل Processor scheduling.

flowchart TB
    accTitle: من العرض أي جهة تشكّ
    accDescr: مخطّط يبيّن أن عدم استقرار الخلفية وحدها عند نقل البؤرة يجعل هذا الإعداد مرشّحاً، وأن التدهور عند التصغير أو على البطارية فقط يدعو إلى الشك في QoS أو الطاقة، وأن زمن DPC/ISR أو التعريف مشكلة أخرى تُحفَر منفصلة.
    smp2["انظر كيف يظهر العرض"] -->|"نقل البؤرة يجعل الخلف غير مستقر"| this1["هذا الإعداد مرشّح"]
    smp2 -->|"تدهور عند التصغير أو البطارية فقط"| qsp1["شكّ في QoS / الطاقة"]
    smp2 -->|"من DPC / ISR أو التعريف"| oth2["مشكلة أخرى لا يصلحها هذا الإعداد"]

الشكل 16: اعتماد العرض على الشروط يدلّك أيّ الثلاثة تشكّ: هذا الإعداد أم QoS أم مشكلة أخرى.

8. النظرة العملية

إن عزلت السبب فعلاً، هذا الترتيب أوضح.

1. ثبّت الشروط
   • تغذية AC أم بطارية
   • وضع الطاقة
   • حجم المخزن المؤقّت
   • حالة foreground / visible / minimized
2. قارن Programs و Background services في الشروط نفسها
   • لا تكتفِ بالإحساس؛ سجّل عدد dropout وglitch وتأخّر المعالجة
3. على Windows 11 / hybrid CPU، شكّ في جانب QoS
   • هل يسوء عند التصغير فقط
   • هل يتغيّر في حالة audible
   • هل يسوء على البطارية فقط
4. للصوت أو الفيديو، انظر MMCSS أولاً
   • هل وصل إلى Windows أن هذا الخيط المهم «موعده حرج»
5. إن لم يُحل، احفر في DPC / ISR / USB / التعريف
   • هنا الكلام قبل scheduler أصلاً

flowchart TB
    accTitle: ترتيب العزل
    accDescr: مخطّط يبيّن ترتيب العزل: تثبيت الشروط أولاً، ثم مقارنة Programs وBackground services في الشروط نفسها، ثم الشك في QoS على hybrid CPU، ثم التحقّق من MMCSS للصوت أو الفيديو، ثم الحفر في DPC/ISR والتعريفات إن بقي الأمر.
    o1["ثبّت الشروط"] --> o2["قارن الإعدادين في الشروط نفسها"]
    o2 --> o3["على hybrid CPU شكّ في QoS"]
    o3 --> o4["للصوت والفيديو تحقّق من MMCSS"]
    o4 --> o5["إن بقي، احفر في DPC / ISR والتعريفات"]

الشكل 17: ابدأ بتثبيت الشروط، واترك طبقات ما قبل scheduler إلى الأخير.

8.1 ماذا تفحص في كل خطوة، وكيف

حتى لا تتوقّف عند «أشك»، هذه وسائل الفحص.

wpr أمر Windows Performance Recorder، وهو ضمن Windows ADK. شغّله من وحدة تحكّم بامتياز مدير.

عملياً، «هل لحق الموعد» أهمّ من متوسّط استخدام CPU. هذا جوهر المسألة.

flowchart TB
    accTitle: المؤشّر الذي ينبغي النظر إليه هو الموعد
    accDescr: مخطّط يبيّن أنه في هذا النوع من المشاكل يكون لحاق المعالجة الدورية بالموعد مؤشّراً أهمّ من متوسّط استخدام CPU.
    avg2["متوسّط استخدام CPU"] -.->|"هذا وحده لا يكفي"| judge1["الحكم على الاستقرار"]
    ddl1["هل لحق الموعد"] -->|"انظر هنا"| judge1
    ddl1 -.-> cnt1["عُدّ بعدد dropout أو glitch"]

الشكل 18: المتوسّط قد يكون منخفضاً والموعد يفوت، فاحكم بعدّ اللحاق.

9. الخلاصة

إن أعدنا صياغة ما يحدث عند نقل Processor scheduling إلى Background services بجمل قصيرة:

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

باختصار: هذا ليس زرّاً يرفع قوّة CPU، بل زرّاً يغيّر توزيع العمل.

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

وفي عصر hybrid CPU تعلو فوق ذلك طبقة QoS واختيار P / E. إن رأيت الطبقتين معاً، ظهر «لماذا ينفع أحياناً» و«لماذا لا ينفع أحياناً».

flowchart TB
    accTitle: موضع هذا الزر في العصر الحالي
    accDescr: مخطّط يبيّن أن هذا الإعداد زرّ يميل التوزيع قليلاً نحو الخلفية، وأن عصر hybrid CPU يضع فوقه طبقة QoS واختيار P-core / E-core، لذلك قد ينفع لكنه ليس البطل وحده.
    knob1["زرّ يميل التوزيع نحو الخلفية"] --> base2["طبقة quantum والتفضيل"]
    base2 -.->|"تعلو فوقها"| upper1["طبقة QoS واختيار P / E"]
    upper1 --> view1["يتّضح سبب النفع وسبب عدمه"]

الشكل 19: هذا الزر يؤثّر في الطبقة السفلى فقط، أما اختيار النواة اليوم فتقرّره الطبقة التي فوقها.

روابط مرجعية

• Sawady, إعداد يفضّل خدمات الخلفية (لا تدع CPU يتكاسل)
• Microsoft Learn, Win32_OperatingSystem class
• Microsoft Learn, شرح قيمة السجل Win32PrioritySeparation - معنى البتّات، والقيمة التي يكتبها اختيار الواجهة.
• Microsoft Learn, Master Your Quantum - quantum لكل قيمة من Win32PrioritySeparation.
• Microsoft Learn, Know Thy Tick - علاقة clock tick بـ quantum.
• Microsoft Learn, CPU Analysis in Windows Performance Analyzer
• Microsoft Learn, Windows Performance Recorder
• 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

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما الذي يتغيّر إذا نقلتُ Processor scheduling إلى Background services؟

ما يتغيّر ليس سرعة CPU ولا تردّده، بل طريقة توزيع زمن CPU بين تطبيق الواجهة والعمل الذي يجري في الخلفية. داخلياً هذا إعداد مرتبط بـ Win32PrioritySeparation، ويؤثّر في توزيع quantum (الشريحة الزمنية) وفي درجة تفضيل foreground. خيار Programs يميل إلى تفضيل تطبيق الواجهة، وBackground services يعامل الواجهة والخلفية بمزيد من التساوي. اختيار هذا الإعداد لا يحوّل تطبيقك إلى خدمة Windows.

لماذا قد يصلح Background services طقطقة الصوت أحياناً؟

معالجة الصوت لا يكفي أن تكون سريعة في المتوسّط؛ يجب ملء المخزن المؤقّت قبل deadline كل بضعة ميلي ثانية. تحت Programs يميل تطبيق الواجهة إلى الجري لفترات أطول، فيتأخّر خيط الصوت في الخلفية في تلك اللحظة تحديداً رغم أن المتوسّط سليم، فيحدث underrun. النقل إلى Background services يُضعف تفضيل الواجهة، فيستعيد العمل المستمر في الخلفية CPU بسهولة أكبر، وقد تقلّ حالات فوات الموعد. مشاكل زمن DPC/ISR، وتوفير طاقة USB، وأعطال التعريفات، وthermal throttling، وما ينشأ عن EcoQoS لا يصلحها هذا الإعداد.

هل يجعل Background services عمل الخلفية يعمل على P-cores؟

لا. أي نواة يستقر عليها العمل — P-core أم E-core — تحدّده أقوى QoS وسياسة الطاقة وhybrid scheduling وIntel Thread Director، لا هذا الإعداد. في Windows 11 قد ينخفض QoS بمجرّد تصغير النافذة، وعلى البطارية يوضع العمل أقرب إلى efficient core بسهولة. إن تباطأ الأمر بعد التصغير فقط، أو على البطارية فقط، فالأقرب أن تشكّ في QoS أو في جانب الطاقة قبل أن تلمس هذا الإعداد.

كيف أعزل سبب انقطاع الصوت أو dropout؟

ثبّت الشروط أولاً: تغذية AC أم بطارية، وضع الطاقة، حجم المخزن المؤقّت، وحالة الواجهة / التصغير. ثم قارن Programs مع Background services في الشروط نفسها، وسجّل عدد dropout وزمن تأخّر المعالجة. على hybrid CPU في Windows 11 انظر إن كان التدهور يظهر عند التصغير فقط أو على البطارية فقط، وعندها شكّ في QoS. للصوت أو الفيديو تحقّق أولاً من أن الخيوط المهمّة مسجّلة في MMCSS. إن لم يُحل الأمر، احفر في DPC/ISR وUSB والتعريفات. من هنا لم يعد الأمر مسألة scheduler.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.