From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6570 invoked by alias); 16 Apr 2016 17:39:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 6548 invoked by uid 89); 16 Apr 2016 17:39:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:pinskia, seriously, pinskiagmailcom, U*pinskia X-HELO: mx-out01.mykolab.com X-Spam-Score: -2.9 Date: Sat, 16 Apr 2016 17:39:00 -0000 From: Siddhesh Poyarekar To: pinskia@gmail.com Cc: Szabolcs Nagy , Carlos O'Donell , GNU C Library , nd@arm.com, Ramana Radhakrishnan , Marcus Shawcroft Subject: Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.) Message-ID: <20160416173854.GB4831@devel.intra.reserved-bit.com> References: <56D8A849.1020109@redhat.com> <56D9CBCB.2060207@arm.com> <56DA02C5.7030208@redhat.com> <56DDBB64.9050800@arm.com> <20160415151020.GA4831@devel.intra.reserved-bit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SW-Source: 2016-04/txt/msg00424.txt.bz2 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? 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. 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/