You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any tips/starters on benchmarking/assigning/limiting CPU cache usage (on x64 Linux with systemd, initially with XOrg and on Manjaro/Arch)? But, while still using GNOME/similar + Firefox/VS Code.
(Without using cgroups directly, if possible.) Any GitHub/other CI tips, and local Mac OS tips, are welcome (but initially focused on local Linux with XOrg).
To partially isolate L1+L2 caches, we could use taskset or systemd-run to attach Firefox/VS Code to one hardware core, and the benchmarked app (single process, single threaded) to another hardware core. But, that doesn't handle L3.
And/or, any easy ways to restrict cores & CPU caches of GNOME/window manager itself:
not starting GNOME login automatically at boot, or
applying systemd and/or cgroups to existing GNOME/window manager processes,
any other window managers,
Wayland vs. XOrg
other ways?
(OK to link/include C/x64 assembly, as far as it's friendly to LLVM. OK to limit it to pre-NUMA Intel generations only, at least initially).
(OK with unsafe and/or Rust's own nightly-only benchmarking framework (instead of Criterion). As of May 2024, benches/shared/lib_benches.rs uses Criterion, but we can move away from it easily.)
The text was updated successfully, but these errors were encountered:
peter-lyons-kehl
changed the title
Benchmarking locally: isolating CPU caches
Benchmarking: assigning/affinity of CPU caches
May 18, 2024
Any tips/starters on benchmarking/assigning/limiting CPU cache usage (on x64 Linux with
systemd
, initially with XOrg and on Manjaro/Arch)? But, while still using GNOME/similar + Firefox/VS Code.(Without using
cgroups
directly, if possible.) Any GitHub/other CI tips, and local Mac OS tips, are welcome (but initially focused on local Linux with XOrg).To partially isolate L1+L2 caches, we could use
taskset
orsystemd-run
to attach Firefox/VS Code to one hardware core, and the benchmarked app (single process, single threaded) to another hardware core. But, that doesn't handle L3.And/or, any easy ways to restrict cores & CPU caches of GNOME/window manager itself:
systemd
and/orcgroups
to existing GNOME/window manager processes,Wayland
vs.XOrg
(OK to link/include C/x64 assembly, as far as it's friendly to LLVM. OK to limit it to pre-NUMA Intel generations only, at least initially).
(OK with
unsafe
and/or Rust's ownnightly-only
benchmarking framework (instead ofCriterion
). As of May 2024, benches/shared/lib_benches.rs usesCriterion
, but we can move away from it easily.)The text was updated successfully, but these errors were encountered: