This is the mail archive of the mailing list for the glibc 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: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)

On Sat, Apr 16, 2016 at 10:38 AM, Siddhesh Poyarekar
<> wrote:
> On Fri, Apr 15, 2016 at 03:09:38PM -0700, 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?

> 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.


> 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]

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