פורסם: 17/11/2010 - 11:07
נושא ההודעה: בקרוב: שיפור בתגובתיות של לינוקס תחת עומס כבד על המעבד
|
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
הייתי שולח את זה בתור ידיעה לאתר, אבל אני לא מבין מספיק איך זה עובד
בכל אופן, לינוס בעצמו לא מתבייש להתלהב בקול רם, וזה דבר חריג למיטב זכרוני. הטלאי הזה לא ייכנס כנראה לגירסה הקרובה של הקרנל אלא לזו שאחריה. אני מניח שבימים הקרובים אנשים יתחילו להעלות לרשת חבילות עם הטלאי זה לשירות הציבור.
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 13:02
נושא ההודעה:
|
כמה שאלות:
1. מתי אמורה להגיע גירסה 2.6.38 (בה אמור להיות הטלאי הזה)?
2. מה זה בדיוק אומר task groups per TTY? איך זה עובד?
3. איך אפשר לשלב את זה כבר עכשיו? יש הפניה למדריך / חבילות שעושות את זה?
תודה!
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 13:10
נושא ההודעה:
|
1. גירסאות קרנל חדשות יוצאות בזמן האחרון כל שלושה חודשים בערך, וגירסה 2.6.37 נמצאת בשלב די התחלתי של העבודה, אז הייתי מהמר על סביבות מרץ או אפריל 2011.
2. אהמממםםםם...
3. יש לינק בידיעה בפורוניקס לדיון הרלוונטי בפורום שלהם, ושם יש כמה לינקים להנחיות לקימפול קרנלים ושאר דברים שכנראה רלוונטיים לעניין.
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 13:51
נושא ההודעה:
|
ציטוט: | 2. מה זה בדיוק אומר task groups per TTY? איך זה עובד? |
אין לי מושג איך לאכול את זה, אולי אתה ואחרים...
קוד: | Explain how his patch works Mike wrote
Each task’s signal struct contains an inherited pointer to a refcounted autogroup struct containing a task group pointer, the default for all tasks pointing to the init_task_group. When a task calls __proc_set_tty(), the process wide reference to the default group is dropped, a new task group is created, and the process is moved into the new task group. Children thereafter inherit this task group, and increase it’s refcount. On exit, a reference to the current task group is dropped when the last reference to each signal struct is dropped. The task group is destroyed when the last signal struct referencing it is freed. At runqueue selection time, If a task has no cgroup assignment, it’s current autogroup is used.
Simply, this patch works by enabling the system to automatically create task groups per TTY from what I understand. |
What does it do
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 16:49
נושא ההודעה:
|
למי שמתכוון לקמפל את הקרנל שלו בעצמו עם הפאטץ' הזה ולא לחכות
https://patchwork.kernel.org/patch/326472/
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 16:50
נושא ההודעה:
|
עזבו פאצ'ים ושטויות, מוזיקה של מלמסטין בסרטונים - חשוב יותר
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 17:10
נושא ההודעה:
|
mksoft : | עזבו פאצ'ים ושטויות, מוזיקה של מלמסטין בסרטונים - חשוב יותר |
???
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 17:51
נושא ההודעה:
|
אלוהים, אני מסטול
כשראיתי את הסרטונים בידיעה של Phoronix שכחתי שיש לי נגן מוזיקה פועל ברקע ובוחר שירים באקראי. הוא ניגן לי את הקטע הבא של מלמסטין:
http://www.youtube.com/watch?v=TaV-I5C90zk
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 19:26
נושא ההודעה: Re: בקרוב: שיפור בתגובתיות של לינוקס תחת עומס כבד על המעבד
|
Anonymous : |
בכל אופן, לינוס בעצמו לא מתבייש להתלהב בקול רם, וזה דבר חריג למיטב זכרוני. הטלאי הזה לא ייכנס כנראה לגירסה הקרובה של הקרנל אלא לזו שאחריה. אני מניח שבימים הקרובים אנשים יתחילו להעלות לרשת חבילות עם הטלאי זה לשירות הציבור. |
נשמע מגניב, מחכה לזה בקוצר רוח
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 19:30
נושא ההודעה: Re: בקרוב: שיפור בתגובתיות של לינוקס תחת עומס כבד על המעבד
|
דוביקס : | Anonymous : |
בכל אופן, לינוס בעצמו לא מתבייש להתלהב בקול רם, וזה דבר חריג למיטב זכרוני. הטלאי הזה לא ייכנס כנראה לגירסה הקרובה של הקרנל אלא לזו שאחריה. אני מניח שבימים הקרובים אנשים יתחילו להעלות לרשת חבילות עם הטלאי זה לשירות הציבור. |
נשמע מגניב, מחכה לזה בקוצר רוח |
זה גם נראה מגניב, ראית את הסרטונים?
אני ניסיתי לעשות backport לפאטץ' הזה בשביל שיעבוד עם קרנל 2.6.35 אבל לא ממש הצלחתי... אולי עם 2.6.36 יהיה לי יותר מזל.
|
|
חזרה לתוכן הדיון |
פורסם: 17/11/2010 - 19:34
נושא ההודעה:
|
זה שאתה מסטול זה לא חדש
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 00:48
נושא ההודעה:
|
למה מתיחסים לזה רק כשיפור לדסקטופ?
גם בשרת יש פעמים שהוא מריץ אפליקציות מרובות, וה latency משמעותי.
מחשבה נוספת שחשבתי עליה - לגבי סמרטפונים למיניהם בעלי קרנל לינוקס, זה נראה לי מאוד מאוד משמעותי!
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 07:29
נושא ההודעה:
|
ראיתי את הדיווח מפורוניקס ("פלא תבל חדש, ויש לנו כהוכחה benchmark") והנחתי שמדובר על משהו שבין הגזמה להגזמה פראית. קראתי עכשיו את http://lwn.net/Articles/415740 (השבוע זמין רק למנויים) ועכשיו ברור יותר על מה מדובר.
המתזמן (scheduler) של לינוקס נותן באופן כללי זמן שווה לכל המשימות שצריכות את המעבד.
נסתכל על רצף עבודה טיפוסי של לינוס. כאשר הוא צריך לבנות קרנל הוא רוצה שהבניה תסתיים כמה שיותר מהר. לכן הוא מריץ make -j 9 (לניצול של כל 8 הליבות). בינתיים הוא משועמם. במקום להסתייף עם הבן שלו, הוא צופה בסרט במחשב.
כלומר: יש לנו 10 תהליכים שונים שצריכים את המעבד (הנגן ותשעה תהליכי בניה). כולם יקבלו זמן שווה. מה תהיה איכות הוידאו?
הרעיון בתיקון המוצע הוא להגדיר את כל מה שרץ במסוף אחד כ"קבוצת תהליכים", ולדאוג להגינות בין קבוצות התהליכים. במקרה של לינוס זה אומר שהנגן יקבל פתאום 50% מזמן המעבד.
האם המקרה הזה (הרצת עבודות כבדות דווקא מתוך מסוף, ומתוך מסוף בודד) הוא שיפור כזה רציני? אולי. לא נראה לי שזה ישפיע על רוב המשתמשים.
מי שלא רוצה לבנות את הקרנל מחדש: חפשו בקישור של patchowrks את המילים super-complex patch .
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 07:59
נושא ההודעה:
|
סביר שהוא לא משתמש בדרייבר הקינייני של nVidia, אין לו לכן vdpau, והוא נקלע למצוקה שתיאר צפריר.
החטא ועונשו?
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 08:06
נושא ההודעה:
|
לינוס? משתמש בדרייבר קנייני? (שיגרום ל־taint של הקרנל שלו)? שלא תומך ב־KMS?
שימוש בדרייבר הקנייני היה באמת מבזבז את זמנו. לא רק בזמן שהוא מריץ בניות.
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 08:08
נושא ההודעה:
|
תיקון: הוא לא משתמש גם בדרייבר החופשי של nVidia. יש לו כרטיס אינטל.
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c8
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 09:12
נושא ההודעה:
|
צפריר, אינטל HDA זה כרטיס קול, לא כרטיס מסך. הוא בד"כ מובנה בלוחות אם עם Chipset של אינטל.
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 09:23
נושא ההודעה:
|
לולי : | סביר שהוא לא משתמש בדרייבר הקינייני של nVidia, אין לו לכן vdpau, והוא נקלע למצוקה שתיאר צפריר.
החטא ועונשו? |
אולי הוא משתמש בכרטיס של אינטל, גם בכרטיסים של אינטל יש האצת וידאו ותמיכה בvaapi
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 09:24
נושא ההודעה:
|
ik_5 : |
זה שאתה מסטול זה לא חדש |
אם כבר אז תלך על jethro tull
מוזיקה יותר עמוקה
http://www.youtube.com/watch?v=toHlMD50eYY
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 09:28
נושא ההודעה:
|
לינוקס הוא רובין הוד עם חליל לטובת האנושות
יאן הנדרסון האיש עם החליל , הגב הוא הדמות ב shrek 4 והמוזיקה היא שלו בסרט
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 10:42
נושא ההודעה:
|
ציטוט: | ראיתי את הדיווח מפורוניקס ("פלא תבל חדש, ויש לנו כהוכחה benchmark") והנחתי שמדובר על משהו שבין הגזמה להגזמה פראית. קראתי עכשיו את http://lwn.net/Articles/415740 (השבוע זמין רק למנויים) ועכשיו ברור יותר על מה מדובר.
המתזמן (scheduler) של לינוקס נותן באופן כללי זמן שווה לכל המשימות שצריכות את המעבד.
נסתכל על רצף עבודה טיפוסי של לינוס. כאשר הוא צריך לבנות קרנל הוא רוצה שהבניה תסתיים כמה שיותר מהר. לכן הוא מריץ make -j 9 (לניצול של כל 8 הליבות). בינתיים הוא משועמם. במקום להסתייף עם הבן שלו, הוא צופה בסרט במחשב.
כלומר: יש לנו 10 תהליכים שונים שצריכים את המעבד (הנגן ותשעה תהליכי בניה). כולם יקבלו זמן שווה. מה תהיה איכות הוידאו?
הרעיון בתיקון המוצע הוא להגדיר את כל מה שרץ במסוף אחד כ"קבוצת תהליכים", ולדאוג להגינות בין קבוצות התהליכים. במקרה של לינוס זה אומר שהנגן יקבל פתאום 50% מזמן המעבד.
האם המקרה הזה (הרצת עבודות כבדות דווקא מתוך מסוף, ומתוך מסוף בודד) הוא שיפור כזה רציני? אולי. לא נראה לי שזה ישפיע על רוב המשתמשים.
מי שלא רוצה לבנות את הקרנל מחדש: חפשו בקישור של patchowrks את המילים super-complex patch . |
אם הולכים להוסיף לתהליכים איזה מנגנון שמונע "הרעבה" אז יש 2 אפשרויות
ריבוב תהליכים בזמן או פיצול תהליכים לנימים אם יש דבר כזה...
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 11:04
נושא ההודעה:
|
מבחינת המתזמן של לינוקס, נימים (threads) שונים שקולים כמעט לחלוטין לתהליכים שונים.
ההבדל בין שני סוגי המשימות הוא שניגון מוזיקה הוא עבודה אינטראקטיבית, שלא כדאי לעכב אותה. את התהליכים הבונים אפשר לעכב ללא נזק מהותי. לכן צריך לדעת להעדיף תהליכים אינטראקטיביים.
מצד שני, גרסאות קודמות של המתזמן של לינוקס ניסו יותר מדי להעדיף תהליכים אינטראקטיביים. התוצאה לא היתה מספיק טובה.
ר' גם http://en.wikipedia.org/wiki/Completely_Fair_Scheduler
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 11:54
נושא ההודעה:
|
הבעיה היא ששמעת 2-3 שירים שלהם, כאילו שמעת את כולם ... אני מאוד אוהב את הביצוע שלהם ל Bourée וזהו בערך
|
|
חזרה לתוכן הדיון |
פורסם: 18/11/2010 - 22:25
נושא ההודעה:
|
|
|
חזרה לתוכן הדיון |
פורסם: 19/11/2010 - 13:55
נושא ההודעה:
|
ניסיתי.
ולמרות שרציתי להיות סקפטי וכו' - אי אפשר להתעלם מהעובדה שהדסקטופ פשוט יותר "חלק" - עבודה עם חלונות מרובים (כרגיל בשבילי) והרצת תהליכים ברקע לא גורמת יותר לקרטועים (אפילו האנימציות של מיזעור חלון, הזזה, וכו' - הכל פשוט יותר חלק).
אני מאוד מבסוט
|
|
חזרה לתוכן הדיון |
פורסם: 19/11/2010 - 16:27
נושא ההודעה:
|
צפריר : | ראיתי את הדיווח מפורוניקס ("פלא תבל חדש, ויש לנו כהוכחה benchmark") והנחתי שמדובר על משהו שבין הגזמה להגזמה פראית. קראתי עכשיו את http://lwn.net/Articles/415740 (השבוע זמין רק למנויים) ועכשיו ברור יותר על מה מדובר.
המתזמן (scheduler) של לינוקס נותן באופן כללי זמן שווה לכל המשימות שצריכות את המעבד.
נסתכל על רצף עבודה טיפוסי של לינוס. כאשר הוא צריך לבנות קרנל הוא רוצה שהבניה תסתיים כמה שיותר מהר. לכן הוא מריץ make -j 9 (לניצול של כל 8 הליבות). בינתיים הוא משועמם. במקום להסתייף עם הבן שלו, הוא צופה בסרט במחשב.
כלומר: יש לנו 10 תהליכים שונים שצריכים את המעבד (הנגן ותשעה תהליכי בניה). כולם יקבלו זמן שווה. מה תהיה איכות הוידאו?
הרעיון בתיקון המוצע הוא להגדיר את כל מה שרץ במסוף אחד כ"קבוצת תהליכים", ולדאוג להגינות בין קבוצות התהליכים. במקרה של לינוס זה אומר שהנגן יקבל פתאום 50% מזמן המעבד.
האם המקרה הזה (הרצת עבודות כבדות דווקא מתוך מסוף, ומתוך מסוף בודד) הוא שיפור כזה רציני? אולי. לא נראה לי שזה ישפיע על רוב המשתמשים.
מי שלא רוצה לבנות את הקרנל מחדש: חפשו בקישור של patchowrks את המילים super-complex patch . |
האם זה לא בסה"כ שימוש בפיצ'ר cgroups שקיים כבר בקרנל?
הוספתי את השורות האמורות וזה נראה משהו כזה:
קוד: |
ls /dev/cgroup/cpu/user/
2287 cgroup.procs cpu.rt_runtime_us notify_on_release
cgroup.event_control cpu.rt_period_us cpu.shares tasks
|
זה נראה עובד, ויש אולי איזשהו שיפור (מורגש בקושי) בביצועים. על זה כל הרעש?
סתם הערה הם יוצרים את ה- directory עם הרשאות 777 (זה של היוזר שאתם רואים למעלה) לא ברור אם זה תקין.
|
|
חזרה לתוכן הדיון |
פורסם: 19/11/2010 - 18:24
נושא ההודעה:
|
ציטוט: | ולמרות שרציתי להיות סקפטי וכו' - אי אפשר להתעלם מהעובדה שהדסקטופ פשוט יותר "חלק" - עבודה עם חלונות מרובים (כרגיל בשבילי) והרצת תהליכים ברקע לא גורמת יותר לקרטועים (אפילו האנימציות של מיזעור חלון, הזזה, וכו' - הכל פשוט יותר חלק).
אני מאוד מבסוט |
תודה על המשוב
|
|
חזרה לתוכן הדיון |
פורסם: 19/11/2010 - 19:02
נושא ההודעה:
|
נראה לי שזה בדיוק סוג המקומות שבהם כדאי להשתמש ב־1777 (כמו ב־/tmp ) במקום סתם 0777.
|
|
חזרה לתוכן הדיון |
פורסם: 20/11/2010 - 09:10
נושא ההודעה:
|
צפריר : | נראה לי שזה בדיוק סוג המקומות שבהם כדאי להשתמש ב־1777 (כמו ב־/tmp ) במקום סתם 0777. |
בוצע. רק להבין זה בעצם מחלק את זמן ככה שעבור כל הפרוססים שמבוצעים תחת אותו טרמינל הוא יתיחס כאילו זה פרוסס אחד? אז איך זה בדיוק משפר את הביצעים הגראפיים (שאין להם טרמינל?)
|
|
חזרה לתוכן הדיון |
פורסם: 21/11/2010 - 15:54
נושא ההודעה:
|
אחרי שיישמתי את ה"טריק" בבאש, לא יכולתי לנעלות מכונות kvm ע"י libvirt.
הפיתרון: צריך לערוך את הקובץ /etc/libvirt/qemu.conf ולהוסיף את השורה הבאה:
קוד: | cgroup_controllers = [ "cpu" ] |
|
|
חזרה לתוכן הדיון |
|