[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Mark Salyzyn]

Take an effort to recode the arm64 vdso code from assembler to C
previously submitted by Andrew Pinski <apinski@cavium.com>, 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.


Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: James Morse <james.morse@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Andrew Pinski <apinski@cavium.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org

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.

[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Mark Salyzyn]

Take an effort to recode the arm64 vdso code from assembler to C
previously submitted by Andrew Pinski <apinski@cavium.com>, 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@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.


Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: James Morse <james.morse@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Andrew Pinski <apinski@cavium.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org

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.

[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Jon Masters]

On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
> Take an effort to recode the arm64 vdso code from assembler to C
> previously submitted by Andrew Pinski <apinski@cavium.com>, 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.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Jon Masters]

On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
> Take an effort to recode the arm64 vdso code from assembler to C
> previously submitted by Andrew Pinski <apinski@cavium.com>, 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.

-- 
Computer Architect | Sent from my Fedora powered laptop

[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Will Deacon]

On Tue, Oct 31, 2017 at 06:04:19PM -0400, Jon Masters wrote:
> On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
> > Take an effort to recode the arm64 vdso code from assembler to C
> > previously submitted by Andrew Pinski <apinski@cavium.com>, 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.

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

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Will Deacon]

On Tue, Oct 31, 2017 at 06:04:19PM -0400, Jon Masters wrote:
> On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
> > Take an effort to recode the arm64 vdso code from assembler to C
> > previously submitted by Andrew Pinski <apinski@cavium.com>, 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.

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

[PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Mark Salyzyn]

On 11/01/2017 02:40 AM, Will Deacon wrote:
> On Tue, Oct 31, 2017 at 06:04:19PM -0400, Jon Masters wrote:
>> On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
>>> Take an effort to recode the arm64 vdso code from assembler to C
>>> previously submitted by Andrew Pinski <apinski@cavium.com>, 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.
> 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

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

[Mark Salyzyn]

On 11/01/2017 02:40 AM, Will Deacon wrote:
> On Tue, Oct 31, 2017 at 06:04:19PM -0400, Jon Masters wrote:
>> On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
>>> Take an effort to recode the arm64 vdso code from assembler to C
>>> previously submitted by Andrew Pinski <apinski@cavium.com>, 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.
> 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