Forwarded from Software Engineer Labdon
🔵 عنوان مقاله
What Makes System Calls Expensive: A Linux Internals Deep Dive (18 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد چرا syscall در Linux گران است: عبور از مرز user به kernel باعث برهمزدن وضعیت ریزمعماری CPU میشود؛ از تخلیه pipeline و پاکسازی پیشبینی انشعاب تا بههمخوردن return stack buffer. در مسیر ورود/خروج syscall، kernel علاوه بر جابهجایی بین stack و گاه page table (در نتیجهٔ KPTI)، مجموعهای از دفاعها علیه حملات حدسی مثل Spectre را اعمال میکند؛ اقداماتی مانند IBPB/IBRS/STIBP، retpoline و RSB stuffing که همگی چرخههای اضافی مصرف میکنند. نتیجه این است که بخش بزرگی از هزینه، صرف خودِ تغییر سطح دسترسی و بازسازی بهینهسازیهای CPU میشود، نه منطق اصلی kernel.
نمونهٔ روشن آن vDSO است که clock_gettime را در user-space فراهم میکند و بر اساس بنچمارکها حدود ۸۹٪ سریعتر از نسخهٔ syscall عمل میکند؛ یعنی خودِ عبور به kernel گلوگاه اصلی است. پیام عملی برای توسعهدهندگان این است که در مسیرهای داغ از فراوانی syscall بکاهند: از vDSO برای زمان، batching و I/O برداری، و راهکارهایی مانند io_uring یا async I/O استفاده کنند و نتایج تکراری را cache نمایند. جمعبندی: هزینهٔ syscall بیشتر از برهمخوردن وضعیت ریزمعماری و ملاحظات امنیتی ورود/خروج ناشی میشود و پرهیز از این عبورها میتواند بهبود چشمگیری در کارایی ایجاد کند.
#Linux #Syscalls #Kernel #Performance #Microarchitecture #Spectre #vDSO #io_uring
🟣لینک مقاله:
https://blog.codingconfessions.com/p/what-makes-system-calls-expensive?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What Makes System Calls Expensive: A Linux Internals Deep Dive (18 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد چرا syscall در Linux گران است: عبور از مرز user به kernel باعث برهمزدن وضعیت ریزمعماری CPU میشود؛ از تخلیه pipeline و پاکسازی پیشبینی انشعاب تا بههمخوردن return stack buffer. در مسیر ورود/خروج syscall، kernel علاوه بر جابهجایی بین stack و گاه page table (در نتیجهٔ KPTI)، مجموعهای از دفاعها علیه حملات حدسی مثل Spectre را اعمال میکند؛ اقداماتی مانند IBPB/IBRS/STIBP، retpoline و RSB stuffing که همگی چرخههای اضافی مصرف میکنند. نتیجه این است که بخش بزرگی از هزینه، صرف خودِ تغییر سطح دسترسی و بازسازی بهینهسازیهای CPU میشود، نه منطق اصلی kernel.
نمونهٔ روشن آن vDSO است که clock_gettime را در user-space فراهم میکند و بر اساس بنچمارکها حدود ۸۹٪ سریعتر از نسخهٔ syscall عمل میکند؛ یعنی خودِ عبور به kernel گلوگاه اصلی است. پیام عملی برای توسعهدهندگان این است که در مسیرهای داغ از فراوانی syscall بکاهند: از vDSO برای زمان، batching و I/O برداری، و راهکارهایی مانند io_uring یا async I/O استفاده کنند و نتایج تکراری را cache نمایند. جمعبندی: هزینهٔ syscall بیشتر از برهمخوردن وضعیت ریزمعماری و ملاحظات امنیتی ورود/خروج ناشی میشود و پرهیز از این عبورها میتواند بهبود چشمگیری در کارایی ایجاد کند.
#Linux #Syscalls #Kernel #Performance #Microarchitecture #Spectre #vDSO #io_uring
🟣لینک مقاله:
https://blog.codingconfessions.com/p/what-makes-system-calls-expensive?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Codingconfessions
What Makes System Calls Expensive: A Linux Internals Deep Dive
An explanation of how Linux handles system calls on x86-64 and why they show up as expensive operations in performance profiles
🔵 عنوان مقاله
Revisiting DDR5-6400 vs. MRDIMM-8800 Performance With Intel Xeon 6 "Granite Rapids"
🟢 خلاصه مقاله:
با عرضه Xeon 6 «Granite Rapids»، اینتل پشتیبانی از DDR5-6400 و همچنین MRDIMM تا 8800 MT/s را فراهم کرد. پس از انتشار نخستین بنچمارکهای مستقل روی Xeon 6900P، اکنون با بهروزرسانی فریمور و بهبودهای اخیر Linux، مقایسه DDR5-6400 و MRDIMM-8800 دوباره بررسی شده است. جمعبندی کلی نشان میدهد MRDIMM-8800 در بارکارهای پهنایباند-محور (مانند تحلیل داده جریانی، پایگاهدادههای درونحافظه و برخی سناریوهای HPC/AI) برتری محسوسی دارد، در حالیکه DDR5-6400 در موارد بهشدت حساس به تأخیر میتواند عملکرد بهتری ارائه دهد. علاوه بر این، نتایج تازه اثرات توان و حرارت را نیز برجسته میکنند: نرخهای بالاتر MRDIMM به بودجه توان و خنکسازی حساستر است، اما در ازای آن توان عملیاتی بالاتری به ازای هر سوکت فراهم میکند. در نتیجه، برای Granite Rapids توصیه میشود در بارهای مقیاسپذیر و پهنایباندی از MRDIMM استفاده شود و در سرویسهای کمتأخیر یا محدود به انرژی/خنکسازی، DDR5 گزینه مناسبتری است.
#Intel #Xeon6 #GraniteRapids #MRDIMM #DDR5 #Linux #Datacenter #Performance
🟣لینک مقاله:
https://www.phoronix.com/review/ddr5-6400-mrdimm-8800
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Revisiting DDR5-6400 vs. MRDIMM-8800 Performance With Intel Xeon 6 "Granite Rapids"
🟢 خلاصه مقاله:
با عرضه Xeon 6 «Granite Rapids»، اینتل پشتیبانی از DDR5-6400 و همچنین MRDIMM تا 8800 MT/s را فراهم کرد. پس از انتشار نخستین بنچمارکهای مستقل روی Xeon 6900P، اکنون با بهروزرسانی فریمور و بهبودهای اخیر Linux، مقایسه DDR5-6400 و MRDIMM-8800 دوباره بررسی شده است. جمعبندی کلی نشان میدهد MRDIMM-8800 در بارکارهای پهنایباند-محور (مانند تحلیل داده جریانی، پایگاهدادههای درونحافظه و برخی سناریوهای HPC/AI) برتری محسوسی دارد، در حالیکه DDR5-6400 در موارد بهشدت حساس به تأخیر میتواند عملکرد بهتری ارائه دهد. علاوه بر این، نتایج تازه اثرات توان و حرارت را نیز برجسته میکنند: نرخهای بالاتر MRDIMM به بودجه توان و خنکسازی حساستر است، اما در ازای آن توان عملیاتی بالاتری به ازای هر سوکت فراهم میکند. در نتیجه، برای Granite Rapids توصیه میشود در بارهای مقیاسپذیر و پهنایباندی از MRDIMM استفاده شود و در سرویسهای کمتأخیر یا محدود به انرژی/خنکسازی، DDR5 گزینه مناسبتری است.
#Intel #Xeon6 #GraniteRapids #MRDIMM #DDR5 #Linux #Datacenter #Performance
🟣لینک مقاله:
https://www.phoronix.com/review/ddr5-6400-mrdimm-8800
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Revisiting DDR5-6400 vs. MRDIMM-8800 Performance With Intel Xeon 6 "Granite Rapids"
One of the exciting elements of Intel's Xeon 6 Granite Rapids launch last year was introducing support for MRDIMMs alongside DDR5-6400 memory support.
🔵 عنوان مقاله
Intel Compute Runtime 25.35.35096.9 Ships Newest Features & Optimizations
🟢 خلاصه مقاله:
اینترال نسخه Intel Compute Runtime 25.35.35096.9 را بهعنوان بهروزرسانی ماهانه جدید منتشر کرد؛ نسخهای که با هدف افزودن قابلیتها و بهینهسازیهای تازه برای پشته متنباز محاسبات GPU این شرکت ارائه شده و پشتیبانی از OpenCL و Level Zero را روی GPUهای مجتمع و مجزا فراهم میکند. این انتشار بر بهبود کارایی، پایداری و تجربه توسعهدهنده تمرکز دارد تا اجرای روانتر بارهای کاری محاسباتی در حوزههایی مانند GPGPU، یادگیری ماشین، محاسبات علمی و پردازش رسانهای امکانپذیر شود. توسعهدهندگان با ارتقای نسخه به 25.35.35096.9 میتوانند از آخرین اصلاحات و بهینهسازیها بهرهمند شوند و با همگامماندن با چرخه ماهانه پروژه، سازگاری و قابلیت اطمینان بهتری به دست آورند.
#Intel #ComputeRuntime #OpenCL #LevelZero #GPUCompute #Drivers #Performance #OpenSource
🟣لینک مقاله:
https://www.phoronix.com/news/Intel-Compute-25.35.35096.9
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Intel Compute Runtime 25.35.35096.9 Ships Newest Features & Optimizations
🟢 خلاصه مقاله:
اینترال نسخه Intel Compute Runtime 25.35.35096.9 را بهعنوان بهروزرسانی ماهانه جدید منتشر کرد؛ نسخهای که با هدف افزودن قابلیتها و بهینهسازیهای تازه برای پشته متنباز محاسبات GPU این شرکت ارائه شده و پشتیبانی از OpenCL و Level Zero را روی GPUهای مجتمع و مجزا فراهم میکند. این انتشار بر بهبود کارایی، پایداری و تجربه توسعهدهنده تمرکز دارد تا اجرای روانتر بارهای کاری محاسباتی در حوزههایی مانند GPGPU، یادگیری ماشین، محاسبات علمی و پردازش رسانهای امکانپذیر شود. توسعهدهندگان با ارتقای نسخه به 25.35.35096.9 میتوانند از آخرین اصلاحات و بهینهسازیها بهرهمند شوند و با همگامماندن با چرخه ماهانه پروژه، سازگاری و قابلیت اطمینان بهتری به دست آورند.
#Intel #ComputeRuntime #OpenCL #LevelZero #GPUCompute #Drivers #Performance #OpenSource
🟣لینک مقاله:
https://www.phoronix.com/news/Intel-Compute-25.35.35096.9
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Intel Compute Runtime 25.35.35096.9 Ships Newest Features & Optimizations
Intel shipped the Compute Runtime 25.35.35096.9 as their newest monthly feature update to this open-source GPU compute stack for their integrated and discrete graphics wares for providing OpenCL and Level Zero support.