From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63180 invoked by alias); 11 May 2017 02:17:15 -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 63109 invoked by uid 89); 11 May 2017 02:17:14 -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=workload, representative, perfect X-HELO: mail-qk0-f181.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fvRZ7hjMjOtW5E99UcZfjntpRAHG+vOmzh6yeKxXrfY=; b=p3VKOEJIhT3C1EzOrvAXsttlzYIL5ciwGXyqThpJ6GkGb1ktBoZXkobxvPeq1JmGSd vXooHQtmepUvbGL9gOdhfHyTPMGTijRjP2VsyhlWu1eCjvK84ylnwGnEONqHcZPPWWSC 1YJNRrBOh2UgAv0k0mpI9TyDFAWuyxcJj7Fb/jIo4axHBsHqBIWfwICehXfCr/VfCs2o 12K1eFi1OMqf2/L6ZKpoX3npngPreU15Ee4cyGKiS5w6Jm4znA+UImZdApbc/h2lhyF7 PsXUyb0W2t6WH9h0/fKufJlfVNK1TPs8FAmZ6TtfH3oDl1Wedz8X1975GuiMMAFkcaC6 rDDg== X-Gm-Message-State: AODbwcDmW+fu5IWL3wWravVqMxy6pO2QLWi9Oxd3I1LXDuFsBHxdyWiz b89fm1W7bJKzzhwuvKGSSA== X-Received: by 10.55.111.67 with SMTP id k64mr8367848qkc.56.1494469033625; Wed, 10 May 2017 19:17:13 -0700 (PDT) Subject: Re: memcpy performance regressions 2.19 -> 2.24(5) To: "H.J. Lu" , Erich Elsen Cc: GNU C Library References: <9c563a4b-424b-242f-b82f-4650ab2637f7@redhat.com> From: Carlos O'Donell Message-ID: <28e34264-e8c5-5570-c48c-9125893808b2@redhat.com> Date: Thu, 11 May 2017 02:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00272.txt.bz2 On 05/10/2017 01:33 PM, H.J. Lu wrote: > On Tue, May 9, 2017 at 4:48 PM, Erich Elsen wrote: >> store is a net win even though it causes a 2-3x decrease in single >> threaded performance for some processors? Or how else is the decision >> about the threshold made? > > There is no perfect number to make everyone happy. I am open > to suggestion to improve the compromise. > > H.J. I agree with H.J., there is a compromise to be made here. Having a single process thrash the box by taking all of the memory bandwidth might be sensible for a microservice, but glibc has to default to something that works well on average. With the new tunables infrastructure we can start talking about ways in which a tunable could influence IFUNC selection though, allowing users some kind of choice into tweaking for single-threaded or multi-threaded, single-user or multi-user etc. What I would like to see as the output of any discussion is a set of microbenchmarks (benchtests/) added to glibc that are the distillation of whatever workload we're talking about here. This is crucial to the community having a way to test from release-to-release that we don't regress performance. Unless you want to sign up to test your workload at every release then we need this kind of microbenchmark addition. And microbenchmarks are dead-easy to integrate with glibc so most people should have no excuse. The hardware vendors and distros who want particular performance tests are putting such tests in place (representative of their users), and direct end-users who want particular performance are also adding tests. -- Cheers, Carlos.