תזמון המעבד ב-Windows - שירותי רקע וליבות P/E

“כשמוציאים את היישום מהחזית, השמע מנתק” “כשמעבירים את ‘תזמון המעבד’ ל’שירותי רקע’, זה נהיה יציב”

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

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

flowchart TB
    accTitle: מה ההגדרה הזו משנה
    accDescr: תרשים המראה שהגדרת תזמון המעבד היא לא הגדרה שמעלה שעון, ולא הופכת ליישום שירות או קובעת לליבת P, ומה שמשתנה הוא אופן חלוקת זמן ה-CPU בין החזית לתהליך שמאחור.
    st1["הגדרת תזמון המעבד"] -.->|"אלה לא משתנים"| notx["שעון · הפיכה לשירות · קיבוע ליבה"]
    st1 -->|"מה שכן משתנה"| shr1["אופן חלוקת זמן ה-CPU בין חזית לעורף"]

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

במאמר הזה נסדר מה משתנה בין תוכניות לשירותי רקע, מהיסודות של תזמן Windows, דרך quantum (פרוסת זמן), העדפת ה-foreground, ועד ההתנהגות ב-CPU עם ליבות P /‏ E.

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

תחילה, רק את עיקרי הדברים:

• מה שההגדרה הזו משנה ישירות הוא לא “כוח הסוס” של ה-CPU, אלא “אופן החלוקה” של זמן ה-CPU.
• ‏תוכניות נוטה להעדיף את היישום שבחזית, ו-שירותי רקע נוטה לטפל בחזית ובעורף בצורה שווה יותר.
• לכן, בעומסי עבודה שבהם מועד תהליך מתמשך שמאחור חשוב יותר מה-UI שבחזית, שירותי רקע עשוי להשפיע.
• עם זאת, ב-CPU עם ליבות P /‏ E, “לאיזו ליבה נטענים” נקבע היום חזק יותר על ידי QoS, מדיניות חשמל, hybrid scheduling ו-Intel Thread Director, ולא רק על ידי ההגדרה הזו.
• כלומר, בחירה ב-שירותי רקע לא הופכת אוטומטית ל”עיבוד רקע לליבת E” או “שירות לליבת P” בפשטות.
• אם הניתוקים או ה-dropout בשמע מקורם ב-DPC /‏ ISR,‏ חיסכון בחשמל ב-USB, דרייבר,‏ thermal throttling, או EcoQoS, ההגדרה הזו לבדה לא תתקן.

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

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

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

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

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

מפת הידע של המאמר

הגדרת ‘תזמון המעבד’ קשורה פנימית לערך רישום בשם Win32PrioritySeparation, ומחליפה רק את אורך ה-quantum ואת מידת ההעדפה המחולקים בין foreground ל-background — היא אינה משנה ישירות את תדר המעבד או שיבוץ לליבה מסוימת. העדפת ‘שירותי רקע’ מחלישה את העדפת ה-foreground, ולכן היא עשויה להקטין תופעות underrun, למשל בעיבוד שמע הרגיש למועדי סיום — אך זהו מנגנון שונה מהעלאת העדיפות שמבצע MMCSS. ב-Windows המודרני, ובמיוחד במעבדי hybrid עם ליבות P/E, השיבוץ בפועל לליבה מושפע יותר מהגדרה זו על ידי Windows QoS ומדיניות heterogeneous scheduling כמו Intel Thread Director; מזעור החלון או הפעלה על סוללה בלבד עלולים להוריד את ה-QoS ולהטות את השיבוץ לכיוון ליבות efficient. לצורך אבחון הסיבה, מומלץ להיעזר בתיעוד השהיית DPC/ISR באמצעות Windows Performance Recorder ו-Analyzer.

flowchart LR
    accTitle: מפת הידע של הגדרת תזמון המעבד ו-QoS
    accDescr: תרשים המראה שהגדרת תזמון המעבד היא מנגנון ישן שקשור ל-Win32PrioritySeparation ומחליף בין חלוקת quantum להעדפת foreground, שכיצד MMCSS ו-Windows QoS משפיעים על underrun ועל שיבוץ לליבות P או E, שמדיניות Intel Thread Director ו-heterogeneous scheduling קובעות את בחירת הליבה במעבד hybrid, ואת אמצעי הבדיקה של השהיית DPC/ISR.
    processor_scheduling_setting["הגדרת תזמון המעבד"]
    windows_qos["סיווג ה-QoS (איכות שירות) של Windows"]
    win32priorityseparation["Win32PrioritySeparation"]
    quantum["‏quantum (פרוסת זמן)"]
    foreground_boost["העדפת תהליך החזית"]
    audio_underrun["underrun (תת-הזנה)"]
    mmcss["MMCSS(Multimedia Class Scheduler Service)"]
    efficient_core_placement["שיבוץ מוטה אל efficient core"]
    ecoqos["EcoQoS"]
    disableuserpresenceqos["DisableUserPresenceQos"]
    hybrid_scheduling_policy["מדיניות heterogeneous scheduling‏ (SchedulingPolicy וכדומה)"]
    intel_thread_director["Intel Thread Director"]
    p_core_e_core_cpu["מבנה P-core/E-core‏ (מעבד היברידי)"]
    core_parking["Core Parking"]
    dpc_isr_latency["השהיית DPC/ISR"]
    wpr_wpa["WPR/WPA(Windows Performance Recorder/Analyzer)"]
    processor_scheduling_setting -->|"מוגדר באמצעות"| win32priorityseparation
    quantum -->|"מוגדר באמצעות"| win32priorityseparation
    processor_scheduling_setting -->|"משתמש ב"| quantum
    processor_scheduling_setting -->|"משתמש ב"| foreground_boost
    processor_scheduling_setting -.->|"מצמצם"| audio_underrun
    mmcss -->|"מצמצם"| audio_underrun
    mmcss -->|"משתמש ב"| windows_qos
    windows_qos -.->|"עלול לגרום ל"| efficient_core_placement
    ecoqos -->|"עלול לגרום ל"| efficient_core_placement
    disableuserpresenceqos -.->|"מונע"| efficient_core_placement
    hybrid_scheduling_policy -->|"משתמש ב"| windows_qos
    hybrid_scheduling_policy -.->|"משתמש ב"| intel_thread_director
    hybrid_scheduling_policy -->|"מחייב"| p_core_e_core_cpu
    intel_thread_director -->|"מחייב"| p_core_e_core_cpu
    hybrid_scheduling_policy -->|"משתמש ב"| core_parking
    dpc_isr_latency -->|"נבדק באמצעות"| wpr_wpa
    p_core_e_core_cpu -->|"נבדק באמצעות"| wpr_wpa
    dpc_isr_latency -.->|"עלול לגרום ל"| audio_underrun

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 18, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. מה ההגדרה הזו בעצם משנה

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

מה שכדאי לקבוע כאן קודם הוא היסוד של איך Windows משתמש ב-CPU.

• התזמן קודם בוחר מבין השרשורים הניתנים להרצה, את בעל העדיפות הגבוהה ביותר.
• באותה עדיפות, מריצים לפי תור, במשך זמן קבוע כל אחד.
• “הזמן הקבוע” הזה הוא ה-quantum (פרוסת הזמן).

flowchart LR
    accTitle: הזרימה הבסיסית של תזמן Windows
    accDescr: תרשים המראה שהתזמן בוחר מתוך השרשורים הניתנים להרצה את בעל העדיפות הגבוהה, מריץ אותו quantum אחד, ואם יש שרשור ממתין באותה עדיפות עובר אליו בהחלפת הקשר.
    ready["שרשורים ניתנים להרצה"] --> pick["התזמן בוחר את בעל העדיפות הגבוהה"]
    pick --> run["מריץ quantum אחד"]
    run --> wait{"יש שרשור ממתין באותה עדיפות?"}
    wait -- כן --> switch["החלפת הקשר"]
    switch --> pick
    wait -- לא --> run

איור 3: התזמן בוחר את השרשור בעל העדיפות הגבוהה, ומריץ אותו quantum אחד בכל פעם, לפי תור.

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

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

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

flowchart TB
    accTitle: הבלבול בשם "שירותי רקע"
    accDescr: תרשים המראה שגם אם בוחרים שירותי רקע, היישום לא הופך לשירות Windows, ומה שמשתנה הוא רק כלל חלוקת ה-CPU בין חזית לעורף.
    sel2["בוחרים 'שירותי רקע'"] -.->|"זה לא קורה"| svcx["היישום הופך לשירות Windows"]
    sel2 -->|"מה שמשתנה"| rule1["כלל חלוקת ה-CPU בין חזית לעורף"]

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

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

ההגדרה הזו נמצאת עמוק למדי בלוח הבקרה. יש שני מסלולי גישה.

• הרצת SystemPropertiesPerformance.exe דרך Win + R פותחת ישירות את “אפשרויות ביצועים”. בלשונית “הגדרות מתקדמות” שלה נמצא תזמון המעבד.
• אם עוברים ידנית: “מאפייני המערכת” > לשונית “הגדרות מתקדמות” > “ביצועים” “הגדרות” > לשונית “הגדרות מתקדמות”. “מאפייני המערכת” עצמם נפתחים עם sysdm.cpl.

תוצאת הבחירה נכתבת לערך הבא ברישום המערכת:

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

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

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

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

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

‏תזמון המעבד שב”אפשרויות ביצועים” קיים גם ב-Windows 10 /‏ Windows 11 ללקוח, וגם ב-Windows Server. עם זאת, הנקודה שקשה להבין בהגדרה הזו היא שאותו ערך מתפרש אחרת בלקוח ובשרת.

בהסבר הרשמי של Microsoft לרישום המערכת, Win32PrioritySeparation מתואר כמסכת ביטים בת 6 ביטים, מחולקת לשלוש קבוצות של 2 ביטים כל אחת (AABBCC).

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

בהתאם לכך, נכתב שהבחירה ב-UI כותבת את הערכים הבאים (הכתיב המקורי ב-UI היה Applications ו-Background services, שמתאימים ל-תוכניות ו-שירותי רקע של היום).

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

כלומר, צד שירותי רקע הוא חלוקה שבה הזמן שרץ בכל פעם ארוך, אבל לא מעדיפים רק את החזית. פחות סביר שהעיבוד שמאחור ייכנס למצב שבו “התור לא מגיע אליו”.

flowchart TB
    accTitle: אופן חלוקת ה-quantum בשתי ההגדרות
    accDescr: תרשים המראה שבהגדרת תוכניות, החזית מקבלת 6 tick והעורף 2 tick, ובהגדרת שירותי רקע שניהם 12 tick, כך שהזמן שרץ בכל פעם ארוך אך לא מועדפת רק החזית.
    pg1["הגדרת 'תוכניות'"] --> fg6["חזית 6 tick · עורף 2 tick"]
    bg2["הגדרת 'שירותי רקע'"] --> eq12["חזית ועורף 12 tick כל אחד"]
    eq12 --> nofam1["פחות סביר שהעורף לא יגיע לתורו"]

איור 6: צד אחד מריץ את החזית זמן ארוך, וצד שני מחלק את אותו זמן ארוך באופן שווה.

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

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

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

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

3. מה משתנה בין תוכניות ל-שירותי רקע

ההבדל בין השניים ברור יותר בטבלת השוואה.

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

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

• עיבוד שמע שממשיך למלא חוצץ ברציפות מאחור
• לכידה או ניתוח שרצים ברציפות בשרשור נפרד / תהליך נפרד, גם כש-UI קל
• מקרה שבו רוצים לשמור על מועד העיבוד שמאחור, גם כשבחזית פתוחים דפדפן או IDE
• עומס עבודה שמוטה לצד שרת, שירות, או תהליך קבוע

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

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

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

4. למה זה יכול להשפיע על שמע ועיבוד מתמשך

קל יותר להבין עם דוגמה של ניתוקי שמע ו-dropout.

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

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

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

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

לעומת זאת, אם מטים לכיוון שירותי רקע, קל יותר לתהליך המתמשך שמאחור להחזיר לעצמו CPU, וקשה יותר להחמיץ את המועד.

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

• העדפת החזית נחלשת מעט
• מספר וזמני הפעמים שהעורף יכול לחדור משתפרים
• כתוצאה מכך, החמצות מועד פוחתות

זרימה כזו.

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

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

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

אם מסתכלים קצת יותר לעומק, המנגנון להשפעה נראה כך.

5.1 quantum ארוך גורם לצד שכנגד באותה עדיפות להמתין יותר

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

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

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

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

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

5.2 Windows מתחשב ב-foreground בכמה צורות

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

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

כלומר, רק הוצאת יישום מהחזית כבר משנה רגילה את הטיפול בו בתזמון. שירותי רקע קל יותר להבין כשמתייחסים אליו כמכוון להקטין, מתוך העדפת ה-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 להתעצל” מובן מבחינת תחושה. במובן שהעיבוד שמאחור פחות נדחק, זה נכון.

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

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

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

flowchart TB
    accTitle: המשמעות המדויקת של "לא להתעצל"
    accDescr: תרשים המראה שמה שבאמת משתנה בהגדרה הזו הוא לא בקרת ה-idle או התדר של ה-CPU, אלא הסדר ואורך ההרצה של השרשורים, ולא turbo, C-state, חניית ליבות או קיבוע ליבת P.
    sabo1["התחושה של 'לא לתת ל-CPU להתעצל'"] -->|"מה שבאמת משתנה"| ord2["הסדר ואורך ההרצה"]
    sabo1 -.->|"מה שלא משתנה"| pw2["turbo · C-state · חניית ליבות · קיבוע ליבה"]

איור 12: המהות של “לא להתעצל” היא לא בקרת חשמל, אלא שינוי בסדר ובאורך ההרצה.

6. איך זה משפיע ב-CPU עם ליבות P /‏ E

זו הנקודה שהכי קל לטעות בהבנתה.

בחירה ב-שירותי רקע לא אומרת ש-Windows קובע בפשטות “זה עיבוד רקע אז ליבת E”, “זה חזית אז ליבת P”. ב-Windows המודרני, ובפרט ב-CPU היברידי של Windows 11, בחירת ליבת P /‏ E היא רב-שלבית הרבה יותר.

6.1 שם דומה, אבל דבר שונה

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

1. שירותי רקע שב-תזמון המעבד
   • הגדרה שבתוך UI ותיק
   • משפיעה בעיקר על אופן חלוקת זמן ה-CPU בין foreground ל-background
   • מהתחום של quantum ו-foreground boost
2. ‏Utility /‏ Eco /‏ Low וכדומה ב-QoS
   • חלוקת power / performance של Windows המודרני
   • משפיעה גם על בחירת ליבה וגם על בקרת תדר
   • קשורה ישירות להתנהגות ליבות P /‏ E

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

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

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

6.2 QoS ו-visibility ב-Windows 11

ב-Windows המודרני, לא רק priority אלא גם QoS משפיע. בפרט במעבד heterogenous, כלומר בהרכב עם ליבות P /‏ E, ה-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. כלומר, במחשב נייד עם CPU היברידי, זה קורה בשגרה:

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

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

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

6.3 Thread Director ו-hybrid scheduling

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

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

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

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

התמונה הכוללת ברורה יותר כך:

flowchart TB
    accTitle: התמונה הכוללת של גורמי בחירת הליבה
    accDescr: תרשים המראה שעדיפות דינמית, QoS, מצב תצוגה וקלט, מדיניות hybrid scheduling, ורמזי Intel Thread Director מתכנסים יחד לתזמן של Windows וניהול חשמל המעבד, וקובעים בסופו של דבר את ליבת P או E ואת התדר.
    t["שרשור"] --> p["עדיפות / עדיפות דינמית"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["מצב תצוגה / השמעה / קלט"]
    t --> h["מדיניות hybrid scheduling (SCHEDPOLICY / SHORTSCHEDPOLICY)"]
    t --> td["רמזי Intel Thread Director (Windows 11 על מעבד היברידי של Intel)"]
    v --> q
    p --> s["תזמן Windows + ניהול חשמל המעבד"]
    q --> s
    h --> s
    td --> s
    s --> c["נקבעים ליבת P / E והתדר"]

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

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

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

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

במקרים כאלה, שירותי רקע יכול להיות פתרון הגיוני.

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

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

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

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

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

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

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

8. איך רואים בעבודה מעשית

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

1. מקבעים תנאים
   • הזנת AC או סוללה
   • מצב חשמל
   • גודל חוצץ
   • מצב foreground / visible / minimized
2. משווים בין תוכניות ל-שירותי רקע באותם תנאים
   • לא רק בתחושה, אלא מתעדים מספר dropout, מספר glitch, ועיכוב עיבוד
3. ב-Windows 11 / CPU היברידי, חושדים בצד QoS
   • האם ההחמרה רק במזעור
   • האם משתנה במצב audible
   • האם ההחמרה רק בסוללה
4. בשמע או וידאו, בודקים קודם MMCSS
   • האם השרשור החשוב מעביר ל-Windows את המסר “יש כאן מועד חשוב”
5. אם עדיין לא נפתר, חופרים ל-DPC /‏ ISR /‏ USB / דרייבר
   • כאן זה כבר נושא שמעבר לתזמן עצמו

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

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

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. סיכום

אם מנסחים בקצרה מה קורה כשמעבירים את תזמון המעבד ל-שירותי רקע, זה נראה כך:

• מה שמשתנה הוא לא מהירות ה-CPU עצמה, אלא אופן חלוקת זמן ה-CPU בין foreground ל-background
• ‏תוכניות מקל על תחושת היישום שבחזית
• ‏שירותי רקע הופך את התהליך המתמשך שמאחור לפחות נדחק
• לכן, במקרים כמו שמע, וידאו, לכידה, ניטור ותהליך קבוע, שבהם המועד שמאחור חשוב, זה עשוי להשפיע
• עם זאת, ב-CPU עם ליבות P /‏ E, מיקום הליבה בפועל מושפע חזק גם מ-QoS, מדיניות חשמל, hybrid scheduling ו-Thread Director
• לכן, ב-Windows של היום, טבעי להתייחס להגדרה הזו כעשויה להשפיע, אבל לא שחקן ראשי בלעדי

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

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

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

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

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

10. מקורות

• Sawady: הגדרה שמעדיפה שירותי רקע (לא לתת ל-CPU להתעצל)
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: הסבר ערך הרישום Win32PrioritySeparation - משמעות הביטים, והערך שהבחירה ב-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

מאמרים קשורים

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

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה משתנה כשמעבירים את 'תזמון המעבד' ל'שירותי רקע'?

לא משתנה מהירות ה-CPU או השעון, אלא אופן חלוקת זמן ה-CPU בין היישום שבחזית לתהליך שרץ מאחור. מבחינה פנימית זו הגדרה שקשורה ל-Win32PrioritySeparation, והיא משפיעה על אופן חלוקת ה-quantum (פרוסת הזמן) ועל מידת העדפת ה-foreground. 'תוכניות' נוטה להעדיף את היישום שבחזית, ו'שירותי רקע' נוטה לטפל בחזית ובעורף בצורה שווה יותר. שווה לציין שגם אם בוחרים בהגדרה הזו, היישום שלכם לא הופך לשירות Windows.

למה בחירה ב'שירותי רקע' לפעמים מתקנת ניתוקי שמע?

כי עיבוד שמע לא מסתפק ב'מהיר בממוצע' — צריך למלא חוצץ עד מועד שנקבע כל כמה מילישניות. בהגדרת 'תוכניות', היישום שבחזית נוטה לרוץ פרקי זמן ארוכים יותר, ועיבוד השמע שמאחור, גם אם בממוצע תקין, לפעמים מתעכב בדיוק באותו רגע והופך ל-underrun. הטיה לכיוון 'שירותי רקע' מקלה על התהליך שמאחור להחזיר לעצמו CPU, ולפעמים מפחיתה החמצות מועד. עם זאת, בעיות שמקורן בהשהיית DPC/ISR, חיסכון בחשמל ב-USB, תקלת דרייבר, throttling תרמי, או EcoQoS — לא נפתרות בהגדרה הזו.

האם הבחירה ב'שירותי רקע' גורמת לתהליכי הרקע לרוץ על ליבת P?

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

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

קודם מקבעים תנאים כמו הזנת AC, מצב חשמל, גודל חוצץ, ומצב חזית/מזעור, ואז משווים תחת אותם תנאים בין 'תוכניות' ל'שירותי רקע' ומתעדים מספר dropout ועיכוב עיבוד. ב-CPU היברידי של Windows 11, בודקים אם ההחמרה קורית רק במזעור או בסוללה ואז חושדים ב-QoS. בשמע או וידאו, בודקים תחילה אם השרשור החשוב מצליח להשתמש ב-MMCSS, ואם עדיין לא נפתר, חופרים ל-DPC/ISR,‏ USB ודרייברים. בשלב הזה זה כבר נושא שמעבר לתזמן עצמו.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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