Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)
Andrew Pinski
pinskia@gmail.com
Tue May 10 06:34:00 GMT 2016
On Sat, Apr 16, 2016 at 10:38 AM, Siddhesh Poyarekar
<sid@reserved-bit.com> wrote:
> On Fri, Apr 15, 2016 at 03:09:38PM -0700, pinskia@gmail.com wrote:
>> I gave an alternative to this approach by passing midr via the aux
>> vector. It still is useful and we can change the kernel to have it
>> return unknown for those known values which will be used for
>> big.little. I don't have a link to my implementation right now
>> though as I am traveling. This is much safer and easier to the
>> black listing inside the kernel and the aux vector is basically free
>> no open/read/close from ifunc or early launch either.
>
> Is this[1] the patch you're referring to?
Yes.
> It seems reasonable to me
> given that we can never support big.little reliably with hotplug
> potentially mixing things up. But it really depends on how seriously
> we want to consider the possibility of having optimal routines for
> big.little systems.
I personally don't have any big.little system which I need to optimize
for. I need to optimize for ThunderX series of processors. I already
have a memcpy for ThunderX and a memset that I optimized but it is
dependent on this kernel patch being approved.
Thanks,
Andrew
>
> We could probably make this patch play nicely with Suzuki's patchset
> and use the auxvec entry as a first check and then fall back to
> trawling sysfs or do the vdso function call if we ever need to
> implement optimal routines for a big.little system. However if
> optimizing for big.little is a serious possibility then it makes sense
> to solve that problem right now instead of burying it temporarily.
>
> Siddhesh
>
> [1] https://patches.linaro.org/patch/52856/
More information about the Libc-alpha
mailing list