Closed NogradThGin closed 1 year ago
Here is a little example (approximativaly 1 minute between the 2 commands)
I started the first just after closing Steam (which, 5 minutes later, is still alive) The second was started few seconds, at most 1 minute later
Hello @NogradThGin
Could you please show me the values of tt tunables https://github.com/hamadmarri/TT-CPU-Scheduler#sysctls
Yes.
Here are my tunables (non-modified, after a fresh reboot)
~ ❯❯❯ sudo sysctl -a | grep sched_tt
kernel.sched_tt_balancer_opt = 2
kernel.sched_tt_batch_prio = 19
kernel.sched_tt_cpu_bound_prio = -15
kernel.sched_tt_dedicated_cpu_bound_enabled = 1
kernel.sched_tt_interactive_prio = -10
kernel.sched_tt_lat_sens_enabled = 1
kernel.sched_tt_max_lifetime = 22000
kernel.sched_tt_rt_prio = -20
Try these values
dedicated_cpu_bound_enabled = 0 lat_sens_enabled = 0 *_prio = 0 For the last one, all rt, interactive … change them to 0
Please let me know if this fixes the issue.
Hotfixing it with the above settings seem to solve the issue, will check on a fresh reboot with a /etc/sysctl.d/ conf file. Yep, I confirm it's way more reactive and behave like any other kernels now. I will start testing each of the above settings to find out which one is the problem here.
Just tested with the following config file /etc/sysctl.d/00-sched-tt.conf
:
### Default values
kernel.sched_tt_balancer_opt = 0
kernel.sched_tt_batch_prio = 19
kernel.sched_tt_cpu_bound_prio = -15
kernel.sched_tt_dedicated_cpu_bound_enabled = 1
# kernel.sched_tt_interactive_prio = -10
kernel.sched_tt_lat_sens_enabled = 1
kernel.sched_tt_max_lifetime = 22000
kernel.sched_tt_rt_prio = -20
### Custom values
kernel.sched_tt_interactive_prio=0
All is running fine and clean now. For an unknown reason the interactive priority is the one making trouble here.
Update after replacing the MOBO. It was indeed the one making TT scheduler totally unstable with the interactive priority. No real clue on why (except it's a Gigabyte mobo).
Received and replaced it today with an Asus, modified back interactive priority to -10. Now working like a charm.
Hello, Since kernels 6.1 and above (did not tested with 6.0) I can't use TT CPU Sched.
All actions requiring an interaction with my GPU (AMD RX 6800 XT) are all drastically long. Quick example: Starting xterm: 0.03s Starting alacritty: 29.11s
Same goes for Steam, or Chromium (even with HW Accel off). If we talk about games, for an unknow reason back 3~4 days ago I succesfully started AIM Lab, benchmarking it with MangoHud (linux-xanmod-tt [5.15] vs linux-xanmod-tt-uksm-cjktty [6.1.8]) gave about 30% perfomance gain.
While writing those lines, I re-tried some GPU software. It appear that TT Sched some take it sweet time to start a full communication with the GPU. After 15~20 mins of uptime, the PC finally seem fully ready to do his job. EDIT: Nah, nevermind, sometime he seem ready, sometime he seem sleepy
Distro: ArchLinux CPU: AMD R9 5950X (SMT off, no diff with it) RAM: 64Go G.Skill 3600Mhz (F4-3600C16-16GTZNC) GPU: AMD RX 6800 XT Midnight Edition MOBO: Gigabyte X570 Gaming X (Rev 1.0) (I highlyyyyyy suspect that this little fu**er to be the culprit here) WM: AwesomeWM (official repo) Driver: Either it is Vulkan (AMDVLK, AMDGPU-Pro and RADV) or OpenGL (Mesa and AMDGPU-Pro) problem happen.
With Kernel 5.15-Xanmod-TT from Chaotic-AUR, no problems. With Kernel 6.1.8-Xanmod-TT problem appear. No problems with other CPU Sched such as Bore, CFS, PDS, BMQ (Kernel 6.2.7 TKG compiled at the same time as this one).
Except for my MOBO suspicion that I would like to replace to validate it is it that create this problem. All of my analysis point to CPU Sched for the hang problem.
Any idea on what I can do to solve/investigate further the problem ?
Any help, or comparisons with similar installation (AMD CPU & GPU combo) are very welcome. It would help me determinate if the problem is my MOBO / or any other part or if it is the CPU Sched or my config that is problematic.
Thanks for the reading.