This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: Check GLIBC_IFUNC to enable/disable ifunc features
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 29 Jun 2016 20:22:15 -0700
- Subject: Re: PATCH: Check GLIBC_IFUNC to enable/disable ifunc features
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOq1+_rMbs1mt3=Md=Wx=7ZxUbD+BhOx-qrO5TBRBrRLww at mail dot gmail dot com> <20160630030947 dot GD3824 at devel dot intra dot reserved-bit dot com>
On Wed, Jun 29, 2016 at 8:09 PM, Siddhesh Poyarekar
<siddhesh@sourceware.org> wrote:
> On Wed, Jun 29, 2016 at 11:15:22AM -0700, H.J. Lu wrote:
>> The current IFUNC selection is based on microbenchmarks in glibc. It
>> should give the best performance for most workloads. But other choices
>> may have better performance for a particular workload or the hardware
>> is too new to make the best choice. We provide an environment variable,
>> GLIBC_IFUNC=xxx=0:yyy=1:zzz=0...., to enable CPU/ARCH feature yyy,
>> disable CPU/ARCH feature yyy and zzz, where the feature name is
>
> I'm afraid this scheme of values is going to hard to parse under
> tunables. Tunables themselves have the same kind of syntax when used
> with a single environment variable. How about having a single
> environment variable for each feature, such as GLIBC_IFUNC_X86_AVX and
> so on instead?
GLIBC_IFUNC must be processed after init_cpu_features is called and before
any relocation is performed. Otherwise, IFUNC won't work correctly. Can your
tunable scheme support it?
--
H.J.