This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] AArch64 optimized memset


On 16 January 2013 15:29, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 16 Jan 2013, Marcus Shawcroft wrote:
>
>> This patch provides an AArch64 optimzied memset implementation.
>
> You have two macros DONT_USE_DC and MAYBE_VIRT in this code, but no
> configure options to set them.  It seems unfortunate if a libc configured
> with the default configuration is unsuitable for virtualized environments,
> for example.  Shouldn't you have appropriate ways to configure these
> things, documented in the installation manual, with safe defaults if the
> user doesn't use any special options?  (The default could use IFUNC to
> select between different versions based on the system being used, I
> suppose.)

This implementation, as configured,  will function correctly on a
virtualized environment.

The implementation has been written to provide a default
implementation that has reasonable behavior across a range of ARMv8
uArchs and a range of environments.  The code is derived from and is
functionally identical to the code linaro has published in their
cortex strings library.
I expect that in due course we will gain IFUNC support for AArch64
glibc and that we will see IFUNC'd memset implementations specifically
optimized to specific AArch64 uArch implementations.

The two macros were provided in the original cortex strings
implementation to provide flexibility to users of that library.  In
the context of glibc I believe the correct configuration is to enable
the use of DC, we really do want to exploit that mechanism as widely
as possible.  We should expect that any sane multiprocessor
environment will implement the same DC clear length on all cores, or
if they really must have different DC clear lengths on each core, then
the dczid_el0 and dc zca will need to be virtualized.

Defining MAYBE_VIRT has marginal value in a virtualized environment
where virtualization has disabled the clear cache mechanism.  In this
situation we would avoid repeatedly reading the virtualized dczid_el0
register in order to determine that DC ZVA is disabled.

When porting the code from cortex strings to glibc I did contemplate
striping these macros out along with the code that they gate.  I
decided to leave them in, despite not being used in glibc in order to
keep the implementation as close as possible to the original.

> Is the caching definitely safe if multiple threads on different processors
> are executing the code using the cache at the same time?

Yes.

Cheers
/Marcus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]