From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50648 invoked by alias); 10 May 2016 06:34:40 -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 50581 invoked by uid 89); 10 May 2016 06:34:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:pinskia, U*pinskia, pinskia@gmail.com, pinskiagmailcom X-HELO: mail-lf0-f50.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=U28XgOAGBIjCUImakDUyCq9GQasMgcZ7d7E2SqGE2Ys=; b=cetmtQvMZ0Gbv14tadc4luwhl9tEOwpHo3VJEDF4h+lroU/x9/fOz9+IT+QW6hZ4Ri afwunTDszsOgK44FG/XsHHXFk7DY+cHOxdB/YsNAWnvwIiMGRptF5mXWJdh046yeUWaG 2d1DVPwWQXHVwazoglQmOi5e8rZFqTXppGGzaNQ7JW37Y4HkNU5HePSbIc0tGTOAc0UX nhwWgzBDnpfl05Z+OSU0CsHJKjJ85xUL8yVUVahRfzNLvvdRbP1eam2nZT+GIUbfhUrJ PSywMSPOcdjumfAKIInyJyvKCHCcn/rYivI7Ei750njVMAaPZ32vm4G0WoAn4LRXl3IO gR8g== X-Gm-Message-State: AOPr4FVDQqs4Yv+uPDjB4jfjd390fa22criWZaa2PJgQU7WSLiTEtHCLjKElU/MyihClQKG0WJ6rO4E8T+OIOQ== MIME-Version: 1.0 X-Received: by 10.112.209.73 with SMTP id mk9mr16155498lbc.121.1462862064998; Mon, 09 May 2016 23:34:24 -0700 (PDT) In-Reply-To: <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> <20160416173854.GB4831@devel.intra.reserved-bit.com> Date: Tue, 10 May 2016 06:34:00 -0000 Message-ID: Subject: Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.) From: Andrew Pinski To: Siddhesh Poyarekar Cc: Szabolcs Nagy , "Carlos O'Donell" , GNU C Library , nd , Ramana Radhakrishnan , Marcus Shawcroft Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-05/txt/msg00183.txt.bz2 On Sat, Apr 16, 2016 at 10:38 AM, Siddhesh Poyarekar 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/