From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74635-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 108438 invoked by alias); 10 Nov 2016 09:34:54 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 108315 invoked by uid 89); 10 Nov 2016 09:34:53 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:828, HX-HELO:sk:homiema, online, State
X-HELO: homiemail-a83.g.dreamhost.com
Subject: Re: [libc/string] State of PAGE_COPY_FWD / PAGE_COPY_THRESHOLD
To: Florian Weimer <fweimer@redhat.com>, Andrew Pinski <pinskia@gmail.com>
References: <E122D105-776D-4B9B-A15C-0A7C24BC0910@linaro.org>
 <c05f0be4-6e4b-80cd-ad74-edc16a443b14@linaro.org>
 <193512EC-DC6C-4BDF-8138-1C1F54B30A12@linaro.org>
 <CA+=Sn1nEq4mjH0T1+vcdA9N1Vzo8n5DAvaDkzhzNQB-akJVfjw@mail.gmail.com>
 <FAC7553E-A7FA-4A00-A984-0F2C1D3A2D36@linaro.org>
 <CA+=Sn1=kfWA89LSy15HQjQoLrwYrcyz2bM49uE64t76_0rQd6w@mail.gmail.com>
 <CA+=Sn1kZSb2oH+rne0YnT6SB=5=u_y4KvOztqT58xNR21w8nnQ@mail.gmail.com>
 <db61e598-d6a8-4938-d930-6ebcb2c803ce@redhat.com>
 <CA+=Sn1nPuE45Su=dkfyfn-cci+yagcE0tytTs=x+vyv5AfExhQ@mail.gmail.com>
 <CA+=Sn1=2S4B46SZZyUbEemhYNMK1Fbs6b1BTRx4QXkXp+OVrjQ@mail.gmail.com>
 <933fb521-583a-2074-28c4-365fd392479f@gotplt.org>
 <7b84a831-233f-e2a7-c89c-efbf438ae9e5@redhat.com>
Cc: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
 Adhemerval Zanella <adhemerval.zanella@linaro.org>,
 GNU C Library <libc-alpha@sourceware.org>
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
Message-ID: <1f45b057-6d17-0c03-fe40-1232c43e7f14@gotplt.org>
Date: Thu, 10 Nov 2016 09:34:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <7b84a831-233f-e2a7-c89c-efbf438ae9e5@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-11/txt/msg00388.txt.bz2

On Thursday 10 November 2016 02:59 PM, Florian Weimer wrote:
> Another option would be to get the complete implementation of memcmp
> etc. fom the vDSO, I think.

Hmm, that is an interesting thought.

> In the ARM context, there were also suggestions that we should support
> big/little asymmetric multi-processing.  I hope we don't have to do
> this.  It would seriously limit IFUNC selection and other
> microarchitecture-based optimizations.

Even if we don't actually have optimal routines for big.LITTLE, we still
have to account for the possibility of their existence, hence the need
to peek into all online processors in the hope (because some could be
offline, giving an incorrect view of the system) of guessing the correct
execution environment.

Siddhesh