arm+arm64: vdso unification to lib/vdso/
v4 cover arm+arm64: vdso unification to lib/vdso/
Take an effort to recode the arm64 vdso code from assembler to C previously submitted by Andrew Pinski <[email protected]>, rework it for use in both arm and arm64, overlapping any optimizations for each architecture. But instead of landing it in arm64, land the result into lib/vdso and unify both implementations to simplify future maintenance. This will act as the basis for implementing arm64 vdso32 in the future.
apinski at cavium.com made the following claims in the original patch:
This allows the compiler to optimize the divide by 1000 and remove the other divides.
On ThunderX, gettimeofday improves by 32%. On ThunderX 2, gettimeofday improves by 18%.
Note I noticed a bug in the old implementation of __kernel_clock_getres; it was checking only the lower 32bits of the pointer; this would work for most cases but could fail in a few.
v2:
- split first CL into 7 pieces, there were cosmetic adjustments.
- make sure profiling is turned off.
- kept quiet_cmd_vdsoas.
v3:
- changed are a result of private email review comments
- rebase
- move arch/arm/vdso/vgettimeofday.c to lib/vdso/vgettimeofday.c
- adjust vgettimeofday.c to be a better global candidate, switch to using ARCH_PROVIDES_TIMER and __arch_counter_get() as more generic.
- do not expose gettimeofday if arch does not support user space timer
v4:
- update commit messages to reflect reasoning here.
- switch to arch_vdso_read_counter as common API.
- split out ARCH_CLOCK_FIXED_MASK.
- Use GENMASK_ULL macro for ARCH_CLOCK_FIXED_MASK.
- dropping forced inline patch and side effects.
- replace all typeof()s with the appropriate types vdso_wtm_clock_nsec_t, vdso_xtime_clock_sec, vdso_raw_time_sec_t, long (tv_nsec) and __kernel_time_t (tv_sec).
- clock_getres implementation, use clock instead of clock_id to match usage elsewhere and remove an inconsistency.
- simplify arm64 implementation of arch_vdso_read_counter, use read_sysreg.
Quoted 7 lines · Mark Salyzyn
Take an effort to recode the arm64 vdso code from assembler to C previously submitted by Andrew Pinski <[email protected]>, rework it for use in both arm and arm64, overlapping any optimizations for each architecture. But instead of landing it in arm64, land the result into lib/vdso and unify both implementations to simplify future maintenance. This will act as the basis for implementing arm64 vdso32 in the future.
In the original patch series, our QE folks found a problem that lead to its revertion from our internal trees. I've pinged them to check this latest version and followup if we see the same failures now.
Jon.
Signature · 1 line
Computer Architect | Sent from my Fedora powered laptop
Quoted 9 lines · Jon Masters
Quoted 7 lines · Mark Salyzyn
Take an effort to recode the arm64 vdso code from assembler to C previously submitted by Andrew Pinski <[email protected]>, rework it for use in both arm and arm64, overlapping any optimizations for each architecture. But instead of landing it in arm64, land the result into lib/vdso and unify both implementations to simplify future maintenance. This will act as the basis for implementing arm64 vdso32 in the future.
Quoted 3 lines
In the original patch series, our QE folks found a problem that lead to its revertion from our internal trees. I've pinged them to check this latest version and followup if we see the same failures now.
Could you elaborate a bit on the problem you found, please? Even if you don't see it with this series, it doesn't mean it isn't lurking somewhere else (potentially even in mainline!).
Will
Quoted 9 lines · Will Deacon
Quoted 8 lines · Jon Masters
Quoted 7 lines · Mark Salyzyn
Take an effort to recode the arm64 vdso code from assembler to C previously submitted by Andrew Pinski <[email protected]>, rework it for use in both arm and arm64, overlapping any optimizations for each architecture. But instead of landing it in arm64, land the result into lib/vdso and unify both implementations to simplify future maintenance. This will act as the basis for implementing arm64 vdso32 in the future.
Quoted 8 lines
Quoted 3 lines
In the original patch series, our QE folks found a problem that lead to its revertion from our internal trees. I've pinged them to check this latest version and followup if we see the same failures now.
Could you elaborate a bit on the problem you found, please? Even if you don't see it with this series, it doesn't mean it isn't lurking somewhere else (potentially even in mainline!).
Will
Interested too!
NB: I expect there can also be some patch series confusion
I have taken two separate, stalling and publicized efforts (arm64 vdso64->C apinski@ and vdso32 Kevin.brodsky@), merged them, tested them, divided them into relatively orthogonal elements, then broke them into smaller independent patch series' (divide and conquer). The final set of vdso32 changes are still pending as I watch each of the three prior smaller patch series' morph on the road to approval. The broken up series created thus far are:
[PATCH] arm64: compat: Remove leftover variable declaration (approved)
[PATCH vx x/3] arm64: compat: Add CONFIG_KUSER_HELPERS (pending)
[PATCH] arm64: compat: Expose offset to registers in sigframes (pending)
[PATCH vx x/12] arm+arm64: vdso unification to lib/vdso (pending, this one)
My suspicion is the final vdso32 changes (blocked by all of these + clangizing, not yet republished as rebased) could be the culprit Jon Masters could be speaking of?
Sincerely -- Mark Salyzyn