performance tuning

Bilingual

ASRock BC-250: Building the Budget Steam Machine
2 months ago
- Overview: ASRock BC-250 offers great value for money and is perfect for DIY enthusiasts.
- Basic setup: Set integrated graphics controller to 'Forces' in chipset, use a single fan, and configure fan curve in BIOS.
- Install cyan-skillfish-smu governor for dynamic GPU clock scaling, improving idle power and gaming performance (instructions for CachyOS and Bazzite provided).
- Configure GPU via /etc/cyan-skillfish-smu/config.toml: adjust frequency range (e.g., 1000-1850 MHz), load targets, and undervolt by reducing voltage safe-points incrementally while testing stability.
- Enable additional compute units (CUs) using BC250 Live Manager script; test stability and write configuration to persist on boot.
- CPU overclocking/undervolt with bc250-smu-oc tool: install stress utility, run detection to find optimal frequency and voltage, and generate overclock.conf.
- Increase shader cache size by adding MESA_SHADER_CACHE_MAX_SIZE=5G to /etc/environment.
Eliminating Go bounds checks with unsafe
3 months ago
- Unsafe pointer arithmetic can be used in Go to eliminate bound checks that the compiler cannot remove, provided the programmer can prove they are unnecessary.
- Bound checks elimination (BCE) reduces instructions and branches, improving performance by lowering cache misses, register pressure, and wasted cycles.
- Go's compiler adds bound checks to prevent out-of-range slice accesses, which can be identified using the -gcflags='-d=ssa/check_bce/debug=1' flag.
- Conventional BCE methods include hinting the compiler by accessing bounds first, but unsafe techniques are needed when the compiler cannot infer safety.
- An unsafe alternative to binary.LittleEndian.Uint32, using unsafe.SliceData and unsafe.Add, eliminates all bound checks and significantly boosts performance in benchmarks.
Preempt_none Is Dead; Your Postgres Probably Doesn't Care
3 months ago
- AWS benchmark showed PostgreSQL throughput dropping to 0.51x on Linux 7.0 vs 6.x due to a regression from removing PREEMPT_NONE preemption mode.
- The performance issue is caused by minor page faults inside a spinlock (buffer_strategy_lock) when using 4KB pages with large shared memory (100+ GB), exacerbated by PREEMPT_LAZY.
- Enabling huge pages (huge_pages=on) eliminates the regression by reducing page faults and TLB pressure, making the kernel upgrade safe for most users.
- Self-hosted servers should configure huge pages properly; containerized setups need host-level huge page reservations or reduced shared_buffers.
- Cloud database users rely on vendors to handle kernel and huge page configurations, with no action required on their part.
- The kernel community suggested using rseq for scheduler hints, but this is not a practical immediate fix; PostgreSQL may adopt it in future versions.
- The benchmark artifact highlights the importance of correct configuration (huge pages) for large shared memory workloads, not a fundamental Linux issue.

performance tuning

ASRock BC-250: Building the Budget Steam Machine

Eliminating Go bounds checks with unsafe

Preempt_none Is Dead; Your Postgres Probably Doesn't Care