Processor scheduling ב-Windows —‏ Background services וליבות P/E

“כשמוציאים את האפליקציה מה-foreground, ה-audio מתחיל לקרוע” “העברנו את Processor scheduling ל-Background services וזה התייצב”

ב-Windows הסיפור הזה עולה כבר שנים. הוא מטריד במיוחד ב-audio, וידאו, מדידה, שידור, ותהליכים resident — מקומות שבהם עבודה רציפה חשובה יותר מה-UI.

אבל זו לא מתג קסם שמאיץ. זו לא הגדרה שמעלה ישירות את ה-clock של ה-CPU, לא הגדרה שהופכת אפליקציה ל-Windows service, ולא הגדרה שמקבעת thread ל-P-core. מה שמשתנה בעיקר הוא איך Windows מחלק CPU time בין האפליקציה שב-foreground לבין עבודה שרצה מאחוריה.

flowchart TB
    accTitle: מה ההגדרה הזו משנה
    accDescr: תרשים שמראה ש-Processor scheduling אינו מעלה clock, אינו הופך אפליקציה ל-service ואינו מקבע ליבה, ומה שמשתנה הוא חלוקת CPU time בין foreground ל-background.
    st1["הגדרת Processor scheduling"] -.->|"את אלה לא משנים"| notx["clock, הפיכה ל-service, קיבוע ליבה"]
    st1 -->|"מה שכן משתנה"| shr1["חלוקת CPU time בין foreground ל-background"]

איור 1: לא מתג האצה — הגדרה שמחליפה את אופן חלוקת ה-CPU time.

המאמר מסביר מה משתנה בין Programs ל-Background services, וקושר את זה ליסודות של ה-scheduler ב-Windows, ל-quantum (time slice), להעדפת foreground, ולהתנהגות של CPU עם P-core / E-core.

1. קודם המסקנה

קודם העיקרים בלבד.

• מה שההגדרה משנה ישירות הוא לא “הכוח” של ה-CPU, אלא איך מחלקים CPU time.
• Programs נוטה להעדיף את אפליקציית ה-foreground; Background services מתייחס ל-foreground ול-background באופן שווה יותר.
• לכן, בעומסים שבהם ה-deadline של עבודה רציפה ברקע חשוב יותר מ-UI שבחזית, Background services לפעמים עוזר.
• במעבדי P-core / E-core, “על איזו ליבה נוחתים” נקבע היום חזק יותר לפי QoS, מדיניות power, hybrid scheduling ו-Intel Thread Director — לא רק לפי ההגדרה הזו.
• כלומר, בחירה ב-Background services לא אומרת “עבודת רקע ל-P-core” או “service ל-E-core”.
• אם ניתוקי audio או dropout מגיעים מ-DPC / ISR, חיסכון בחשמל ב-USB, דרייבר, thermal throttling או EcoQoS, ההגדרה לבדה לא תתקן אותם.

במשפט אחד: זו לא הגדרת תדר של CPU, אלא הגדרה שמחליפה את כללי התור.

flowchart TB
    accTitle: תמונה כללית של מה שמשפיע ומה שלא
    accDescr: תרשים שמראה ש-Background services עשוי לעזור ל-deadline של עבודה רציפה ברקע, בעוד שבחירת P-core / E-core נקבעת חזק יותר לפי QoS ומדיניות power.
    bgss1["צד Background services"] -->|"לפעמים עוזר"| dl1["deadline של עבודה רציפה ברקע"]
    bgss1 -.->|"נקבע במנגנון אחר"| core1["בחירת P-core / E-core"]
    core1 --> qos1["QoS, מדיניות power, hybrid scheduling"]

איור 2: יכול לעזור ל-deadline, אבל בחירת הליבה נקבעת מחוץ להגדרה הזו.

1.1 מונחים שכדאי לקבע מראש

עד פרק 6 מופיעים מונחים שהמשמעות המלאה שלהם מתבהרת רק בהמשך. לכן מרכזים אותם כאן.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 18, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה ההגדרה הזו באמת משנה

Processor scheduling במסך ההגדרות הוא אחת ממדיניות ה-scheduling הוותיקות של Windows. מבפנים זו הגדרה עם היסטוריה ארוכה, שמחוברת ל-Win32PrioritySeparation.

קודם היסוד: איך Windows משתמש ב-CPU.

• ה-scheduler בוחר קודם מבין ה-threads שאפשר להריץ, את זה עם ה-priority הגבוה ביותר.
• באותו priority, הם רצים לפי תור, כל אחד לפרק זמן קבוע.
• פרק הזמן הקבוע הזה הוא ה-quantum (time slice).

flowchart LR
    accTitle: הזרימה הבסיסית של ה-scheduler ב-Windows
    accDescr: תרשים שמראה שה-scheduler בוחר מבין ה-threads ה-runnable את בעל ה-priority הגבוה ביותר, מריץ אותו quantum אחד, ואם יש thread שמחכה באותו priority עוברים אליו ב-context switch.
    ready["threads ש-runnable"] --> pick["ה-scheduler בוחר את בעל ה-priority הגבוה"]
    pick --> run["רץ quantum אחד"]
    run --> wait{"יש thread שמחכה באותו priority?"}
    wait -- yes --> switch["context switch"]
    switch --> pick
    wait -- no --> run

איור 3: ה-scheduler בוחר את ה-thread עם ה-priority הגבוה ביותר, ומריץ אותו quantum אחד בכל פעם, לפי תור.

מה ש-Processor scheduling נוגע בו בעיקר הוא איך מחלקים את ה-quantum, ו-כמה חזק מעדיפים את ה-foreground.

foreground כאן הוא האפליקציה שבחזית, זו שהמשתמש נוגע בה עכשיו. לעומת זאת, עבודה שהלכה לרקע, worker ב-process נפרד, Windows service, helper process ותהליך resident — נוטים ליפול לצד ה-background.

חשוב: גם אם בוחרים Background services, האפליקציה שלכם לא הופכת ל-Windows service. מה שמשתנה הוא לא סוג שנקרא “service”, אלא כללי חלוקת ה-CPU בין foreground ל-background. השם מבלבל מאוד.

flowchart TB
    accTitle: הבלבול בשם Background services
    accDescr: תרשים שמראה שבחירה ב-Background services אינה הופכת את האפליקציה ל-Windows service, ומה שמשתנה הוא רק כלל חלוקת ה-CPU בין foreground ל-background.
    sel2["בוחרים Background services"] -.->|"זה לא קורה"| svcx["האפליקציה הופכת ל-Windows service"]
    sel2 -->|"מה שמשתנה"| rule1["כלל חלוקת ה-CPU בין foreground ל-background"]

איור 4: בניגוד לשם, מה שמשתנה אינו סוג ה-process אלא כלל החלוקה.

2.1 איך מגיעים למסך ההגדרה

ההגדרה יושבת עמוק ב-Control Panel. יש שני מסלולים.

• מ-Win + R מריצים SystemPropertiesPerformance.exe, ונפתח ישירות “Performance Options”. בלשונית Advanced נמצא Processor scheduling.
• ידנית: System Properties > לשונית Advanced > Performance, Settings > לשונית Advanced. את System Properties עצמם פותחים עם sysdm.cpl.

תוצאת הבחירה נכתבת לערך הבא ב-Registry:

אם רוצים רק לראות את הערך הנוכחי, קוראים אותו ב-PowerShell. כדאי לרשום את הערך שלפני השינוי, כדי שאפשר יהיה לחזור.

flowchart TB
    accTitle: הקשר בין הבחירה ב-UI ל-Registry
    accDescr: תרשים שמראה שבחירה ב-Performance Options נכתבת ל-Win32PrioritySeparation ב-Registry, שאפשר לקרוא את הערך ב-PowerShell, ולכן רושמים אותו לפני השינוי.
    uix2["בחירה ב-UI"] --> regw1["נכתב ל-Win32PrioritySeparation"]
    regw1 --> pr1["קוראים ב-PowerShell"]
    pr1 -.-> keep2["רושמים את הערך לפני השינוי"]

איור 5: הבחירה ב-UI היא ערך Registry, ולכן רושמים את הערך הנוכחי לפני שנוגעים בו.

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

2.2 באילו גרסאות Windows זה חל, ומה הערך אומר

Processor scheduling שב-Performance Options קיים גם ב-Windows 10 / Windows 11 ללקוח וגם ב-Windows Server. הנקודה שמבלבלת היא ש-אותו ערך מתפרש אחרת בלקוח ובשרת.

בתיעוד ה-Registry של Microsoft, Win32PrioritySeparation מתואר כ-bitmask של 6 bits, מחולק לשלוש קבוצות של 2 bits (AABBCC).

• 2 ה-bits העליונים: האם ה-quantum ארוך או קצר
• 2 ה-bits האמצעיים: האם ה-quantum משתנה או קבוע
• 2 ה-bits התחתונים: פי כמה מעדיפים foreground על background (משפיע רק כשה-quantum משתנה)

לפי זה, הבחירה ב-UI כותבת את הערכים הבאים (ב-UI הישן זה היה Applications ו-Background services; היום זה Programs ו-Background services).

אם יורדים למספרים, במאמר ההסבר של Microsoft כתוב שב-0x26 ה-quantum הוא 18 ל-foreground ו-6 ל-background, וב-0x18 שניהם 36. quantum נספר ביחידות של שליש clock tick, ולכן ב-tick זה 6 tick לחזית / 2 tick לרקע, ו-12 tick לשניהם. באותו מאמר מופיעה דוגמה שבה clock tick במכונת x86 multiprocessor היה 15.625 ms; במקרה כזה ההבדל הוא בין “החזית יכולה לרוץ ברצף עד כ-94 ms” לבין “גם החזית וגם הרקע רצים כ-188 ms כל אחד”.

כלומר, צד 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: צד אחד נותן לחזית ריצה ארוכה; הצד השני מחלק את אותו זמן ארוך באופן שווה.

גם ברירת המחדל מתפרשת אחרת לפי סוג ה-OS. בתיעוד של Win32_OperatingSystem אצל Microsoft, ב-Windows ללקוח ברירת המחדל היא quantum משתנה, וה-quantum של אפליקציית ה-foreground ארוך יותר; ב-Windows Server ברירת המחדל היא quantum באורך קבוע. גם בתיעוד ה-Registry כתוב שאותו ערך ברירת מחדל, 0x2, מתפרש בלקוח כ”קצר, משתנה, פי 3 לחזית”, ובשרת כ”ארוך, קבוע, שווה”. לכן שרת נוטה מלכתחילה לצד שמקביל ל-Background services.

flowchart TB
    accTitle: אותו ערך ברירת מחדל מתפרש אחרת בלקוח ובשרת
    accDescr: תרשים שמראה שאותו ערך ברירת מחדל מתפרש בלקוח Windows כקצר, משתנה, פי 3 לחזית, ובשרת כארוך, קבוע, שווה, ולכן שרת נוטה מלכתחילה לצד המקביל ל-Background services.
    dv1["אותו ערך ברירת מחדל"] -->|"בלקוח"| cl2["קצר, משתנה, פי 3 לחזית"]
    dv1 -->|"בשרת"| sv4["ארוך, קבוע, שווה"]
    sv4 -.-> lean1["מלכתחילה מקביל ל-Background services"]

איור 7: לא הערך עצמו מחלק את הפרשנות, אלא צד ה-OS.

המספרים הקונקרטיים כאן מגיעים מתיעוד ומאמרי הסבר של Microsoft מדור Windows 2000 / XP. המיפוי בין ערך ה-Registry לבחירה ב-UI נשאר זהה גם היום, אבל הטיפול בפועל ב-quantum יכול להשתנות בין גרסאות OS, ולכן כדאי לקרוא את המספרים כסדר גודל, לא כקבוע פיזי.

3. מה משתנה בין Programs ל-Background services

ההבדל ברור יותר בטבלה.

Windows ללקוח מכוון בעיקרון לכך שאפליקציית ה-foreground תרגיש טוב. לכן בשימוש שולחני רגיל, Programs הוא הבחירה הטבעית.

יש מקרים שבהם התמונה משתנה.

• עיבוד audio שממשיך למלא buffer ברציפות ברקע
• capture או ניתוח שרצים ברציפות ב-thread נפרד / process נפרד, גם כשה-UI קל
• מצב שבו רוצים לעמוד ב-deadline של העבודה מאחור, גם כשבחזית פתוחים דפדפן או IDE
• עומס שקרוב יותר לשרת, ל-service, או לתהליך resident

במקרים כאלה יציב יותר לתת לעבודה ברקע לקבל CPU בחזרה, במקום להעדיף חזק רק את ה-foreground. במובן הזה Background services לפעמים הגיוני.

flowchart TB
    accTitle: איזו חלוקה מתאימה
    accDescr: תרשים שמראה שבשימוש אינטראקטיבי בשולחן עבודה Programs טבעי, ובעומס שבו ה-deadline ברקע חשוב, Background services מאפשר לרקע לקבל CPU בחזרה בקלות יותר.
    wl1["אופי העומס"] -->|"שימוש אינטראקטיבי"| pgn1["Programs טבעי"]
    wl1 -->|"deadline ברקע חשוב"| bgn1["Background services מועמד"]
    bgn1 --> back2["הרקע מקבל CPU בחזרה בקלות יותר"]

איור 8: הבחירה בין תחושת החזית ל-deadline ברקע קובעת איזה צד עדיף.

4. למה זה לפעמים עוזר ב-audio ובעבודה רציפה

קל יותר לראות את זה דרך ניתוקי audio ו-dropout.

עיבוד audio לא מסתפק ב”מהיר בממוצע”. כל כמה מילישניות, או ביחידה קצרה יותר, צריך למלא את ה-buffer עד הרגע שנדרש. גם אם ניצול ה-CPU נמוך בממוצע, אם ה-thread לא מצליח לרוץ בדיוק באותו רגע — ה-audio נקטע.

מצב קונקרטי אחד:

• בחזית יש דפדפן, UI של DAW, או אפליקציה אחרת
• ברקע, thread של עיבוד audio רץ במחזור קבוע ומזין buffer
• ה-thread הזה לא ב-priority גבוה מדי, וגם לא מנצל מספיק MMCSS או QoS
• ה-CPU עמוס במידה מסוימת

תחת Programs, אפליקציית ה-foreground נוטה לרוץ רצפים ארוכים יותר, ועיבוד ה-audio ברקע — גם אם בממוצע תקין — לפעמים מאחר בדיוק באותו רגע. אם זה נמשך, זה הופך ל-underrun, ואז שומעים ניתוק.

מעבר ל-Background services מקל על העבודה הרציפה ברקע לקבל CPU בחזרה, ומקשה יותר להחמיץ את ה-deadline.

כלומר, כשזה עוזר, מה שקורה אינו “ה-CPU נהיה מהיר יותר”, אלא:

• העדפת החזית נחלשת מעט
• מספר הפעמים והעיתוי שבהם הרקע מצליח לקבל CPU משתפרים
• כתוצאה מכך יורדים deadline miss

זו הזרימה.

flowchart TB
    accTitle: הזרימה שבה ניתוקי audio יורדים
    accDescr: תרשים שמראה שתחת Programs החזית רצה זמן ארוך ועיבוד audio מאחר באותו רגע ומגיע ל-underrun, ואילו הטיה ל-Background services מחלישה את העדפת החזית ומאפשרת לרקע לקבל CPU, ומפחיתה deadline miss.
    fgl1["החזית רצה זמן ארוך"] --> late1["עיבוד audio מאחר באותו רגע"]
    late1 --> ur1["underrun וניתוק"]
    even2["מטים את החלוקה לשווה יותר"] --> take1["הרקע מצליח לקבל CPU בקלות יותר"]
    take1 --> less1["deadline miss יורדים"]

איור 9: כשזה עוזר, ה-CPU לא נהיה מהיר — העבודה ברקע פשוט מספיקה ל-deadline.

5. העיקרון — quantum והעדפת foreground

אם יורדים שכבה אחת, המסלול נראה כך.

5.1 quantum ארוך גורם לצד השני באותו priority לחכות יותר

כשכמה threads מתחרים באותו טווח priority, ככל ש-thread אחד מקבל quantum ארוך יותר, האחרים מחכים יותר בהתאם.

בהגדרה שמעדיפה את אפליקציית ה-foreground, צד ה-foreground נוטה לרוץ ברצף זמן ארוך יותר. אז background ב-priority דומה נוטה יותר לקבל “לא עכשיו”.

בעיבוד כמו audio, וידאו, מדידה מחזורית, polling וניטור — עבודה ש-רוצים שתרוץ מעט-מעט אבל בקביעות — ההבדל הזה משפיע.

flowchart TB
    accTitle: quantum ארוך גורם לצד השני לחכות
    accDescr: תרשים שמראה שכשכמה threads מתחרים באותו priority, ככל שאחד מקבל quantum ארוך יותר האחרים מחכים יותר, וההבדל הזה בולט יותר בעבודה שצריכה לרוץ בקביעות.
    comp1["תחרות באותו טווח priority"] --> long1["צד אחד מקבל quantum ארוך"]
    long1 --> wt2["ה-threads האחרים מחכים יותר"]
    wt2 -.-> perio1["ככל שהעבודה מחזורית, ההבדל בולט יותר"]

איור 10: אורך ה-quantum חוזר ישירות כזמן המתנה של מי שמתחרה באותה רמה.

5.2 Windows מתחשב ב-foreground בכמה דרכים

Windows מלכתחילה משקיע לא מעט ב-foreground. הדוגמאות הייצוגיות:

• העדפת ה-process שהגיע לחזית
• העדפת ה-thread שמחזיק את החלון שקיבל קלט
• boost דינמי ל-priority של thread אחרי סיום I/O

כלומר, רק להוציא אפליקציה מה-foreground כבר משנה את היחס אליה ב-scheduling. Background services מובן יותר אם רואים אותו כמכוון להקטין, מתוך העדפת ה-foreground הזו, בעיקר את ההטיה בחלוקת CPU time.

flowchart TB
    accTitle: הדרכים שבהן Windows מתחשב ב-foreground
    accDescr: תרשים שמראה ש-Windows מתחשב ב-foreground בכמה דרכים — העדפת process בחזית, העדפת thread של חלון שקיבל קלט, ו-boost דינמי אחרי I/O — ולכן רק הוצאה מהחזית כבר משנה את היחס.
    fgc1["העדפת process בחזית"] --> chg2["רק הוצאה מהחזית משנה את היחס"]
    fgc2["העדפת thread של חלון שקיבל קלט"] --> chg2
    fgc3["boost דינמי אחרי I/O"] --> chg2
    chg2 -.-> shrink1["ההגדרה הזו מקטינה את ההטיה בחלוקה"]

איור 11: העדפת החזית היא כמה מנגנונים יחד, וההגדרה הזו משפיעה על ההטיה בחלוקה מתוכם.

5.3 “לא לתת ל-CPU להתעצל” נכון בחצי, ולא מדויק בחצי

הניסוח “לא לתת ל-CPU להתעצל” מובן כתחושה. במובן שעבודה ברקע פחות נדחקת — זה נכון.

מבחינה טכנית מדויק יותר לומר שמה שבאמת משתנה אינו בקרת ה-idle או התדר של ה-CPU עצמו, אלא באיזה סדר ולכמה זמן מריצים threads.

לכן ההגדרה הזו:

• לא מעלה turbo boost
• לא מכבה C-state
• לא משנה ישירות core parking
• לא מקבעת ל-P-core

flowchart TB
    accTitle: המשמעות המדויקת של לא להתעצל
    accDescr: תרשים שמראה שמה שבאמת משתנה אינו בקרת idle או תדר ה-CPU, אלא סדר הריצה ואורך הריצה של threads, ושההגדרה אינה 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 מודרני, ובמיוחד ב-CPU היברידי תחת Windows 11, בחירת P-core / E-core היא רב-שלבית הרבה יותר.

6.1 שם דומה, מנגנון אחר

קודם יש שני דברים עם אווירה דומה בשם, שהם לא אותו דבר.

1. Background services שב-Processor scheduling
   • הגדרה ב-UI ותיק
   • משפיעה בעיקר על חלוקת CPU time בין foreground ל-background
   • שייכת למשפחת quantum ו-foreground boost
2. Utility / Eco / Low וכדומה ב-QoS
   • סיווג power / performance של Windows המודרני
   • משפיע גם על בחירת ליבה וגם על בקרת תדר
   • קשור ישירות להתנהגות P-core / E-core

השניים האלה אינם זהים.

flowchart TB
    accTitle: שם דומה, מנגנון אחר
    accDescr: תרשים שמראה ש-Processor scheduling הוא הגדרה ותיקה שמשפיעה על quantum והעדפת foreground, ואילו QoS הוא סיווג power/performance מודרני שמשפיע על בחירת ליבה ובקרת תדר.
    old2["הגדרת Processor scheduling"] --> qt1["quantum והעדפת foreground"]
    newq1["סיווג QoS"] --> cs2["בחירת ליבה ובקרת תדר"]
    old2 -.->|"אלה לא אותו דבר"| newq1

איור 13: האווירה בשם דומה, אבל השכבה שבה כל אחד משפיע שונה לגמרי.

6.2 QoS ו-visibility ב-Windows 11

ב-Windows מודרני משפיע לא רק priority אלא גם QoS. במעבד heterogeneous, כלומר בהרכב עם P-core / E-core, ה-QoS משפיע על איזה סוג ליבה מועדף.

הסיווג הגס ב-Windows 11 נראה כך:

הטבלה הזו היא ריכוז מחדש של שתי הטבלאות במאמר “Quality of Service” ב-Microsoft Learn: רשימת רמות ה-QoS (High / Medium / Low / Utility / Eco / Media / Deadline), ו-סיווג ה-QoS (המיפוי ממצב תצוגת החלון ל-QoS). זה לא סיווג שהוצא מתצפית. באותו מסמך יש גם כלל ש-process שזוהה כמשמיע קול מטופל כ-High, וגם הסבר ש-thread שלא נכנס לאף אחת מהקטגוריות האלה מוקצה אוטומטית לפי היוריסטיקה כמו priority.

עוד תיאור חשוב למי שמודד: יש תכונה שבה על סוללה, אם אין קלט משתמש לפרק זמן מסוים, ה-QoS של אפליקציית ה-foreground עלול לרדת ל-Medium. בתיעוד יש הערה שבמדידת ביצועים על סוללה כדאי לכבות את התכונה הזו, והדרך היא להגדיר 1 ב-DisableUserPresenceQos (REG_DWORD) תחת HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling. אם בבדיקה אוטומטית בלי קלט מופיע “איטי רק על סוללה”, כדאי לחשוד כאן קודם.

הנקודה החשובה: גם רק מזעור עלול לשנות את ה-QoS. כלומר, במחשב נייד עם CPU היברידי זה קורה בשגרה:

• הוציאו את האפליקציה מהחזית
• בנוסף, מיזערו אותה
• כתוצאה מכך ה-QoS ירד
• היא נוטה יותר לנחות על efficient core
• התחושה או ה-deadline הורעו

flowchart TB
    accTitle: שרשרת ממזעור עד הרעה ב-deadline
    accDescr: תרשים שמראה שבמחשב נייד עם CPU היברידי, הוצאה מהחזית ומזעור מורידים את ה-QoS, ועל סוללה בפרט זה מוביל למיקום מוטה ל-efficient core ולהרעה בתחושה או ב-deadline.
    mn2["הוצאה מהחזית ומזעור"] --> qd1["ה-QoS יורד"]
    qd1 -->|"במיוחד על סוללה"| ec1["מיקום מוטה ל-efficient core"]
    ec1 --> ws1["הרעה בתחושה או ב-deadline"]

איור 14: רק פעולת מזעור עלולה להגיע עד לשיבוץ הליבה.

6.3 Thread Director ו-hybrid scheduling

ב-CPU היברידי של Intel מדור 12 ואילך, Intel Thread Director מעביר רמזים ל-OS. Windows 11 משתמש בזה כדי להחליט בצורה חכמה יותר על הקצאת P-core / E-core.

בנוסף, בצד Windows יש מדיניות של heterogeneous scheduling.

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

אם משאירים אותן ב-Automatic, זה מנגנון שבו ה-OS מחליט לפי QoS והרכב המערכת. מאחורי זה רצים גם ה-core parking engine וה-performance state engine בצד processor power management.

את התמונה הכוללת נוח לראות כך:

flowchart TD
    accTitle: התמונה הכוללת של גורמי בחירת הליבה
    accDescr: תרשים שמראה ש-priority דינמי, QoS, מצב תצוגה וקלט, מדיניות hybrid scheduling ורמזי Intel Thread Director מתכנסים ל-scheduler של Windows ול-processor power management, וקובעים בסוף P-core / E-core ואת התדר.
    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 (SCHEDPOLICY / SHORTSCHEDPOLICY)"]
    t --> td["Intel Thread Director hints (Windows 11 on Intel hybrid)"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["נקבעים P-core / E-core והתדר"]

איור 15: priority, QoS, מצב תצוגה, מדיניות scheduling ורמזי Thread Director מתכנסים, וקובעים את הליבה ואת התדר.

7. מתי זה עוזר, ומתי לא

בעבודה מעשית כדאי להפריד בין מקרים שנוטים להיות מושפעים לבין מקרים שהם בעיה אחרת.

7.1 מקרים שנוטים להיות מושפעים

במקרים כאלה Background services יכול להיות צעד הגיוני.

• כשמעבירים focus לאפליקציה שבחזית, רק העבודה הרציפה ברקע נהיית לא יציבה
• ניצול ה-CPU לא רווי, אבל דווקא ה-deadline של עיבוד מחזורי נופל
• העיבוד הקריטי יושב ב-legacy app / helper process / worker thread, ולא מנצל מספיק MMCSS או QoS
• service או תהליך resident הוא השחקן הראשי, ויציבות העבודה ברקע חשובה יותר מנעימות ה-UI שבחזית

7.2 מקרים שפחות מושפעים, או שהם בעיה אחרת

לעומת זאת, יש בעיות שההגדרה הזו לבדה לא מספיקה להן.

• latency גדול של DPC / ISR
• באג ב-USB controller או ב-audio driver
• השפעה של USB selective suspend או חיסכון בחשמל של המכשיר
• thermal throttling
• השפעת battery saver, power throttling או EcoQoS
• buffer קטן מדי
• האפליקציה כבר משתמשת נכון ב-MMCSS / Deadline, והבעיה במקום אחר

במיוחד במחשב נייד עם Windows 11 + CPU היברידי, השינוי ב-visibility וב-QoS משפיע חזק. אם זה נהיה איטי רק במזעור, או רק על סוללה, כדאי לחשוד ב-QoS / power לפני שנוגעים ב-Processor scheduling.

flowchart TB
    accTitle: איזה כיוון לחשוד לפי התסמין
    accDescr: תרשים שמראה שאם העברת focus מערערת רק את הרקע ההגדרה הזו מועמדת, אם ההחמרה רק במזעור או על סוללה חושדים ב-QoS או power, ואם המקור הוא DPC/ISR או דרייבר זו בעיה אחרת.
    smp2["בוחנים איך התסמין מופיע"] -->|"focus לחזית מערער את הרקע"| this1["ההגדרה הזו מועמדת"]
    smp2 -->|"החמרה רק במזעור / על סוללה"| qsp1["חושדים ב-QoS / power"]
    smp2 -->|"מקור ב-DPC / ISR / דרייבר"| oth2["בעיה אחרת שההגדרה לא פותרת"]

איור 16: תלות התסמין בתנאים אומרת אם מדובר בהגדרה הזו, ב-QoS, או בבעיה אחרת.

8. איך רואים את זה בפועל

לבידוד בפועל, הסדר הבא ברור יותר.

1. מקבעים תנאים
   • AC או סוללה
   • מצב power
   • גודל buffer
   • מצב foreground / visible / minimized
2. משווים Programs מול Background services באותם תנאים
   • לא רק לפי תחושה; מתעדים מספר dropout, מספר glitch, ו-latency של העיבוד
3. ב-Windows 11 / CPU היברידי, חושדים בצד QoS
   • האם זה מחמיר רק במזעור
   • האם זה משתנה במצב audible
   • האם זה מחמיר רק על סוללה
4. ב-audio או וידאו, בודקים קודם MMCSS
   • האם ה-thread הקריטי מעביר ל-Windows את המסר “יש כאן deadline חשוב”
5. אם זה עדיין לא נפתר, חופרים ל-DPC / ISR / USB / driver
   • כאן זה כבר לפני ה-scheduler

flowchart TB
    accTitle: סדר הבידוד
    accDescr: תרשים שמראה שקודם מקבעים תנאים, משווים את שתי ההגדרות באותם תנאים, ב-CPU היברידי חושדים ב-QoS, ב-audio ווידאו בודקים MMCSS, ואם נשאר חופרים ל-DPC/ISR ולדרייבר.
    o1["קיבוע תנאים"] --> o2["השוואת שתי ההגדרות באותם תנאים"]
    o2 --> o3["ב-CPU היברידי, חשד ב-QoS"]
    o3 --> o4["ב-audio/וידאו, בדיקת MMCSS"]
    o4 --> o5["אם נשאר, חפירה ל-DPC / ISR / דרייבר"]

איור 17: הבידוד מתחיל מקיבוע תנאים, והשכבה שלפני ה-scheduler נחפרת אחרונה.

8.1 מה בודקים בכל שלב, ואיך

כדי לא להישאר ב”חושדים” בלבד, אלה אמצעי הבדיקה.

wpr היא הפקודה של Windows Performance Recorder, והיא כלולה ב-Windows ADK. מריצים אותה ממסוף עם הרשאות Administrator.

בעבודה מעשית, “האם הגענו ל-deadline” חשוב יותר מניצול CPU ממוצע. זו נקודה מהותית.

flowchart TB
    accTitle: המדד שבודקים הוא ה-deadline
    accDescr: תרשים שמראה שבסוג הבעיה הזה ניצול CPU ממוצע לבדו לא מספיק, ומה שחשוב יותר הוא האם עיבוד מחזורי עמד ב-deadline.
    avg2["ניצול CPU ממוצע"] -.->|"לבד לא מספיק"| judge1["הערכת יציבות"]
    ddl1["האם עמדנו ב-deadline"] -->|"בזה מסתכלים"| judge1
    ddl1 -.-> cnt1["סופרים לפי מספר dropout או glitch"]

איור 18: גם ממוצע נמוך לא מונע deadline miss, ולכן סופרים אם עמדנו ב-deadline ורק אז מחליטים.

9. סיכום

אם מנסחים בקצרה מה קורה כשמעבירים את Processor scheduling ל-Background services:

• מה שמשתנה אינו מהירות ה-CPU עצמה, אלא חלוקת CPU time בין foreground ל-background
• Programs מקל על תחושת אפליקציית ה-foreground
• Background services הופך עבודה רציפה ברקע לפחות נדחקת
• לכן במקרים כמו audio, וידאו, capture, ניטור ותהליך resident, שבהם ה-deadline ברקע חשוב, זה לפעמים עוזר
• במעבדי P-core / E-core, שיבוץ הליבה בפועל מושפע חזק גם מ-QoS, מדיניות power, hybrid scheduling ו-Thread Director
• לכן ב-Windows של היום טבעי לראות את ההגדרה הזו כ-יכולה לעזור, אבל לא השחקן הראשי לבד

בקיצור, זו לא כפתור שמעלה את כוח ה-CPU, אלא כפתור שמחליף את חלוקת העבודה.

האם להעדיף את תחושת האפליקציה שבחזית, או להקל על עמידה ב-deadline של עבודה ברקע. כשרואים את זה כהגדרה שמטה מעט את האיזון לכיוון background, זה מתחבר.

ובעידן ה-CPU ההיברידי, מעל זה יושבת שכבה נוספת של QoS ובחירת P-core / E-core. כשמסתכלים עד לשם, מתבהרים גם “למה זה לפעמים עוזר” וגם “למה לפעמים זה לא”.

flowchart TB
    accTitle: המקום של הכפתור הזה היום
    accDescr: תרשים שמראה שהכפתור מטה את חלוקת העבודה מעט לכיוון background, אבל בעידן CPU היברידי מעל השכבה הזו יושבות QoS ובחירת P-core/E-core, ולכן זה יכול לעזור אך אינו השחקן הראשי לבד.
    knob1["כפתור שמטה חלוקה לכיוון background"] --> base2["שכבת quantum והעדפה"]
    base2 -.->|"מעליה יושבת"| upper1["שכבת QoS ובחירת P-core / E-core"]
    upper1 --> view1["מתבהרת גם הסיבה שעוזר וגם הסיבה שלא"]

איור 19: הכפתור משפיע רק על השכבה התחתונה; בחירת הליבה היום נקבעת בשכבה שמעליה.

10. מקורות

• Sawady: הגדרה שמעדיפה Background services (לא לתת ל-CPU להתעצל)
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: הסבר ערך ה-Registry Win32PrioritySeparation - משמעות ה-bits, והערך שהבחירה ב-UI כותבת.
• 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 ולא ה-clock. מה שמשתנה הוא איך Windows מחלק CPU time בין האפליקציה שב-foreground לבין עבודה שרצה ברקע. מבפנים זו הגדרה שמחוברת ל-Win32PrioritySeparation, והיא משפיעה על חלוקת ה-quantum (time slice) ועל כמה חזק מעדיפים את ה-foreground. Programs נוטה להעדיף את האפליקציה שבחזית; Background services מתייחס ל-foreground ול-background באופן שווה יותר. בחירה בהגדרה הזו לא הופכת את האפליקציה שלכם ל-Windows service.

למה Background services לפעמים מתקן ניתוקי audio (crackling)?

עיבוד audio לא מספיק בכך שהוא מהיר בממוצע. צריך למלא buffer עד deadline כל כמה מילישניות. תחת Programs, אפליקציית ה-foreground נוטה לרוץ רצפים ארוכים יותר, ו-thread של audio ברקע יכול לאחר בדיוק ברגע שהוא צריך CPU — גם כשבממוצע הכול תקין — ולהגיע ל-underrun. מעבר ל-Background services מחליש את העדפת ה-foreground, כך שעבודה רציפה ברקע מצליחה לקבל CPU בחזרה בקלות יותר, ולפעמים יורדים deadline miss. בעיות שמקורן ב-latency של DPC/ISR, חיסכון בחשמל ב-USB, באג בדרייבר, thermal throttling או EcoQoS לא נפתרות בהגדרה הזו.

האם Background services גורם לעבודת רקע לרוץ על P-core?

לא. על איזו ליבה thread נוחת — P-core או E-core — נקבע חזק יותר לפי QoS, מדיניות power, hybrid scheduling ו-Intel Thread Director, לא לפי ההגדרה הזו. ב-Windows 11, גם רק מזעור אפליקציה יכול להוריד את ה-QoS שלה, ועל סוללה היא נוטה יותר לנחות על efficient core. אם זה נהיה איטי רק אחרי מזעור, או רק על סוללה, כדאי לחשוד ב-QoS או בצד ה-power לפני שנוגעים בהגדרה הזו.

איך מבודדים את הסיבה לניתוקי audio או dropout?

קודם מקבעים תנאים: AC או סוללה, מצב power, גודל buffer, ומצב foreground / minimized. אחר כך משווים Programs מול Background services באותם תנאים, ומתעדים מספר dropout ו-latency של העיבוד. ב-CPU היברידי של Windows 11 בודקים אם זה מחמיר רק במזעור או רק על סוללה, ואז חושדים ב-QoS. ב-audio או וידאו בודקים קודם אם ה-thread הקריטי באמת רשום ל-MMCSS. אם זה עדיין לא נפתר, חופרים ל-DPC/ISR, USB ודרייברים. משם זה כבר לא עניין של ה-scheduler.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.