This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Mon, 9 May 2016 23:34:24 -0700
- Subject: Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)
- Authentication-results: sourceware.org; auth=none
- References: <56D8A849 dot 1020109 at redhat dot com> <56D9CBCB dot 2060207 at arm dot com> <56DA02C5 dot 7030208 at redhat dot com> <56DDBB64 dot 9050800 at arm dot com> <20160415151020 dot GA4831 at devel dot intra dot reserved-bit dot com> <BF58C57C-C232-46C6-8677-48E69E72B4BA at gmail dot com> <20160416173854 dot GB4831 at devel dot intra dot reserved-bit dot com>
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/