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.
🔵 عنوان مقاله
Haiku OS Addressing Slow "git status" Performance Relative To Linux
🟢 خلاصه مقاله:
** پروژه Haiku OS در یک پست وبلاگی تازه، بر بهبود کارایی تمرکز کرده و به‌طور ویژه کندی محسوس git status نسبت به Linux را بررسی می‌کند. تیم با پروفایل‌گیری و مقایسه رفتار با Linux در تلاش است گلوگاه‌هایی مانند پیمایش دایرکتوری و فراخوانی‌های پرتعداد فایل را شناسایی و با بهینه‌سازی در مسیرهای I/O و به‌کارگیری کش، زمان پاسخ را کاهش دهد. این کار علاوه بر بهبود تجربه توسعه‌دهندگان در Haiku OS می‌تواند به ابزارهای مشابه دیگر نیز کمک کند و با مشارکت جامعه ادامه خواهد یافت.
#HaikuOS #git #Linux #Performance #OpenSource #DeveloperTools #OperatingSystems
🟣لینک مقاله:
https://www.phoronix.com/news/Haiku-Slow-Git-Status
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Haiku OS Addressing Slow "git status" Performance Relative To Linux
🟢 خلاصه مقاله:
** پروژه Haiku OS در یک پست وبلاگی تازه، بر بهبود کارایی تمرکز کرده و به‌طور ویژه کندی محسوس git status نسبت به Linux را بررسی می‌کند. تیم با پروفایل‌گیری و مقایسه رفتار با Linux در تلاش است گلوگاه‌هایی مانند پیمایش دایرکتوری و فراخوانی‌های پرتعداد فایل را شناسایی و با بهینه‌سازی در مسیرهای I/O و به‌کارگیری کش، زمان پاسخ را کاهش دهد. این کار علاوه بر بهبود تجربه توسعه‌دهندگان در Haiku OS می‌تواند به ابزارهای مشابه دیگر نیز کمک کند و با مشارکت جامعه ادامه خواهد یافت.
#HaikuOS #git #Linux #Performance #OpenSource #DeveloperTools #OperatingSystems
🟣لینک مقاله:
https://www.phoronix.com/news/Haiku-Slow-Git-Status
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Haiku OS Addressing Slow "git status" Performance Relative To Linux
The BeOS-inspired Haiku open-source operating system project published a new blog post to outline some of their latest development activity
🔵 عنوان مقاله
SquashFS Optimization Achieves 15,277x Performance In Developer Benchmark
🟢 خلاصه مقاله:
توسعه‌دهنده SquashFS یعنی Phillip Lougher امروز پچی حدوداً ۱۰۰ خطی منتشر کرده که در بنچمارک توسعه‌دهنده، برای بعضی عملیات‌ها در این فایل‌سیستم فشرده و فقط‌خواندنی تا ۱۵٬۲۷۷ برابر بهبود کارایی نشان داده است. این جهش عمدتاً به سناریوهای خاص مربوط است و بسته به نوع workload می‌تواند متفاوت باشد، اما در بارهای خواندنِ تکراریِ داده‌های فشرده، اثر آن می‌تواند بسیار چشمگیر باشد. این تغییرات اکنون در حال بررسی هستند و در صورت پذیرش، احتمالاً در نسخه‌های آینده وارد می‌شوند.
#SquashFS #Performance #Optimization #Kernel #Patch #Benchmark #Filesystem #PhillipLougher
🟣لینک مقاله:
https://www.phoronix.com/news/SquashFS-Faster-Sparse-Copy
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
SquashFS Optimization Achieves 15,277x Performance In Developer Benchmark
🟢 خلاصه مقاله:
توسعه‌دهنده SquashFS یعنی Phillip Lougher امروز پچی حدوداً ۱۰۰ خطی منتشر کرده که در بنچمارک توسعه‌دهنده، برای بعضی عملیات‌ها در این فایل‌سیستم فشرده و فقط‌خواندنی تا ۱۵٬۲۷۷ برابر بهبود کارایی نشان داده است. این جهش عمدتاً به سناریوهای خاص مربوط است و بسته به نوع workload می‌تواند متفاوت باشد، اما در بارهای خواندنِ تکراریِ داده‌های فشرده، اثر آن می‌تواند بسیار چشمگیر باشد. این تغییرات اکنون در حال بررسی هستند و در صورت پذیرش، احتمالاً در نسخه‌های آینده وارد می‌شوند.
#SquashFS #Performance #Optimization #Kernel #Patch #Benchmark #Filesystem #PhillipLougher
🟣لینک مقاله:
https://www.phoronix.com/news/SquashFS-Faster-Sparse-Copy
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
SquashFS Optimization Achieves 15,277x Performance In Developer Benchmark
SquashFS developer Phillip Lougher posted a patch today just over one hundred lines of code yielding an outright massive performance gain for some operations with this compressed read-only file-system.
❤2
🔵 عنوان مقاله
Rust Coreutils 0.2.2 Released With Faster base64: Outperforming GNU's base64
🟢 خلاصه مقاله:
** نسخه 0.2.2 از Rust Coreutils به‌سرعت پس از انتشار 0.2 منتشر شد؛ نسخه‌ای که پیش‌تر از بهبودهای «بسیار چشمگیر» در کارایی و پشتیبانی آمادهٔ تولید برای Ubuntu خبر داده بود. در این به‌روزرسانی، مهم‌ترین تغییر سرعت بالاتر دستور base64 است که اکنون می‌تواند از نسخهٔ متناظر در GNU Coreutils عملکرد بهتری ارائه دهد—نقطه عطفی قابل توجه برای یک ابزار بنیادین سیستم‌عاملی. علاوه بر base64، این انتشار چند بهبود دیگر نیز دارد که در ادامهٔ روند نسخهٔ 0.2 بر ارتقای کارایی، پایداری و آمادگی استفاده در محیط‌های تولیدی تأکید می‌کند.
#Rust #Coreutils #base64 #Performance #GNU #Ubuntu #OpenSource #SystemsProgramming
🟣لینک مقاله:
https://www.phoronix.com/news/Rust-Coreutils-0.2.2
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Rust Coreutils 0.2.2 Released With Faster base64: Outperforming GNU's base64
🟢 خلاصه مقاله:
** نسخه 0.2.2 از Rust Coreutils به‌سرعت پس از انتشار 0.2 منتشر شد؛ نسخه‌ای که پیش‌تر از بهبودهای «بسیار چشمگیر» در کارایی و پشتیبانی آمادهٔ تولید برای Ubuntu خبر داده بود. در این به‌روزرسانی، مهم‌ترین تغییر سرعت بالاتر دستور base64 است که اکنون می‌تواند از نسخهٔ متناظر در GNU Coreutils عملکرد بهتری ارائه دهد—نقطه عطفی قابل توجه برای یک ابزار بنیادین سیستم‌عاملی. علاوه بر base64، این انتشار چند بهبود دیگر نیز دارد که در ادامهٔ روند نسخهٔ 0.2 بر ارتقای کارایی، پایداری و آمادگی استفاده در محیط‌های تولیدی تأکید می‌کند.
#Rust #Coreutils #base64 #Performance #GNU #Ubuntu #OpenSource #SystemsProgramming
🟣لینک مقاله:
https://www.phoronix.com/news/Rust-Coreutils-0.2.2
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Rust Coreutils 0.2.2 Released With Faster base64: Outperforming GNU's base64
It was just a few days ago that Rust Coreutils 0.2 released with 'massive' performance gains and production-ready Ubuntu support
❤1