Repository navigation
fix(libkernel): scale the reported TSC frequency under APS5_TIME_SCALE - #12206
Conversation
|
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
The clock model is internally consistent: raw TSC ticks are paired with the scaled reported frequency, while the JobManager spin duration uses the host frequency. The new test checks native rdtsc, sceKernelReadTsc, and the reported frequency together. I found no separate logic issue by static inspection. This branch is 60 commits behind current main; please rebase and rerun the time tests (including scaled and unscaled) on the rebased head before approval.
|
A Windows run, since the description lists none. Head
AI-assisted: yes (Claude Code). |
|
Windows result for head Host: Windows 11 26300, Intel i7-12700K, WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, r6), Release, The tree also carried the open PRs #12290, #12288, #12285, #12269, #12265, #12232, #12201, #12199, #12197, #12165, #12146, all merged cleanly, so the run is a joint one; the tests of this PR are AI-assisted: yes (Claude Code), the runs and the numbers above are from this machine. |
Titles that execute rdtsc themselves ignored APS5_TIME_SCALE, because only sceKernelReadTsc scaled its ticks. The reported TSC frequency is now divided by the scale and sceKernelReadTsc returns raw ticks, so ticks over the reported frequency follow the scale for both. The JobManager worker spin keeps real time through the host frequency. AI-assisted: yes
e80ed4b to
5da3632
Compare
|
Rebased on Rebased on AI-assisted: yes |
What
APS5_TIME_SCALEscaled only the tickssceKernelReadTscreturns. A title that executesrdtscitself and divides bysceKernelGetTscFrequency(ormachdep.tsc_freq) saw real time, so the scale had no effect on it, and its own TSC disagreed withsceKernelReadTsc.The scale now goes into the reported frequency instead:
sceKernelGetTscFrequencyreturns the measured host frequency divided by the scale, andsceKernelReadTscreturns rawrdtsc. Ticks over the reported frequency follow the scale for both, andsceKernelGetProcessTimeCounter, which already counts scaled time at that frequency, stays consistent. The measurement moves toHostTscFrequency_nid_no_patch, which the JobManager worker spin uses so it keeps spinning for real microseconds.Without
APS5_TIME_SCALEnothing changes.Tested
Arch Linux 7.2.11-zen, GCC 16.2.1, Ninja, Release, on
main3ca715e:guest_process_time_rdtscandguest_process_time_rdtsc_scaled(scale 0.5): over a 50 ms sleep, nativerdtscticks andsceKernelReadTscticks over the reported frequency must both come to the scaled time. WithTime.cppfrommain,guest_process_time_rdtsc_scaledfails:native rdtsc ticks over the reported TSC frequency do not follow the time scale.guest_process_time*tests, including test(libkernel): cover sceKernelReadTsc's rate against sceKernelGetTscFrequency #11594'sguest_process_time_tsc_scaled, pass.ctest -j8(this branch together with my five other branches of today, on the samemain): 2619 of 2620 pass;agc_driver_mesh_barycentric_emulationfails the same way onmainon this GPU (the pixel shader did not emulate barycentrics).tools/check_conventions.py --base origin/mainpasses.APS5_TIME_SCALEto chase a timing-dependent crash; no title behaviour is claimed to depend on it.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)