לינוס טורוולדס, מי שמוביל את הקרנל של לינוקס, פרסם את הפאץ' הראשון שלו שנכתב בעזרת מודל שפה. לפי הדיווח של Tom's Hardware, מדובר בסדרת שינויים שמטפלת בעומס על המטמון (cache contention) כשכמה ליבות מעבד קוראות שוב ושוב מאותו קובץ.
הבעיה מוכרת למפתחי מערכות הפעלה. כשכמה ליבות ניגשות בבת אחת לאותו מבנה נתונים, הן מתחרות על אותן שורות מטמון. במקרה הזה המוקד הוא מונה ההפניות של ה-folio, יחידת הניהול של דפי המטמון של הקבצים בקרנל. כל קריאה מעדכנת את המונה הזה, והעדכונים הופכים לצוואר בקבוק ככל שיש יותר ליבות.
מה טורוולדס שלח
טורוולדס לא שלח את השינוי כרשימת פאצ'ים לתפוצה. הוא פרסם אותו כענף בעץ הקוד הציבורי שלו, בשם rcu-free-v3, וציין שהוא מעדיף שמפתחים ימשכו אותו מ-git. לפי ההודעה שפרסם ברשימת התפוצה של הקרנל, מדובר בסדרה קצרה של עשרה פאצ'ים.
השינוי מזהה דפים שנמצאים בשימוש תדיר ודוחה את שחרורם עד לאחר תקופת RCU (קריאה בלי נעילה כבדה). כך אפשר לקרוא את נתוני הדף בתוך קטע מוגן RCU, במקום לעדכן את מונה ההפניות במסלול המהיר. לפי ההודעה, אין צורך בחיץ כפול, והמגבלות של הגישה המוקדמת שלו נעלמו.
מה המספר 23 מודד
טורוולדס כתב שבמבחן שהריץ על מעבד Ryzen Threadripper קצב הקריאות בשנייה עלה מכ-13.3 מיליון לכ-304 מיליון, כלומר פי 23 בערך. הוא הדגיש שזה לא מספר שמשתמש אמיתי יראה: מדובר במבחן סינתטי של קריאה מאותו קובץ. לדבריו, החשיבות היא בכך שהביצועים מתנהגים כמעט כסקיילינג מושלם, בלי כתיבות לשורות מטמון משותפות.
איך ה-AI נכנס לעבודה
טורוולדס כתב שניסה לפתור את הבעיה עוד בתחילת 2024, ושהשתמש בפתרון ראשוני על המחשב הנייד שלו מאז. לפני שהפעיל את מודל השפה לסיום העבודה, הוא כתב שהאתגר היה לפתור את הבעיה שמפתחים אחרים ניסו לתקן במשך שנים בלי פתרון מלא. הוא גם ציין שהודעות הקומיט ארוכות יותר ממה שהיה כותב בעצמו, ושאולי זה טוב כך.
מה עדיין פתוח
השינוי עדיין לא נכנס לקו הראשי, וטורוולדס ביקש הערות על הענף עצמו. השאלה אם הסדרה תעמוד בבדיקה הרגילה של הקרנל, בלי הנחות בגלל מקורה, תגיד הרבה יותר על מקומם של כלי AI בתשתיות מאשר המספר 23 עצמו.
מקורות
מקורות: Tom's Hardware; LWN; ההודעה המקורית של לינוס טורוולדס ברשימת התפוצה של הקרנל