From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-99261-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 34102 invoked by alias); 15 Jan 2019 12:31:00 -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 130900 invoked by uid 89); 15 Jan 2019 12:30:43 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=duty
X-HELO: mx1.redhat.com
Message-ID: <48f6ccf22e6850c056b32aaf12e7c1700bbfaa6a.camel@redhat.com>
Subject: Re: [PATCH] NUMA spinlock [BZ #23962]
From: Torvald Riegel <triegel@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Carlos O'Donell <carlos@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, 
 Szabolcs Nagy <Szabolcs.Nagy@arm.com>, libc-alpha
 <libc-alpha@sourceware.org>
Date: Tue, 15 Jan 2019 12:31:00 -0000
In-Reply-To: <87pnsy5d3z.fsf@oldenburg2.str.redhat.com>
References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local>
	 <7D8A82D6-6F0A-4860-856A-EB0C8CD13E9C@antfin.com>
	 <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com>
	 <c7f11fea-371e-4453-b5d0-9b142632aecc.ling.ml@antfin.com>
	 <8c67f319-31bf-818b-4a89-66d25328026e@arm.com>
	 <CAMe9rOrU1niqVofiFvpgvMNrUohu0yW--OBTHh3TDC-3fnG51Q@mail.gmail.com>
	 <d4b9e25e-8884-b01f-040e-b6f40e011033@redhat.com>
	 <CAMe9rOr9yeey0H2R1H6LRQxiFJ1Eu2fc+sqs+J2t1aaJBFcC5g@mail.gmail.com>
	 <87ef9oe0zf.fsf@oldenburg2.str.redhat.com>
	 <CAMe9rOqJu8gmrjZd10_YU7bo4gUGOETYvsE4mGd=vZK2hH4_Dg@mail.gmail.com>
	 <97275e72-dc1b-fc2a-d908-b94ef7064ed8@redhat.com>
	 <87y37siic1.fsf@oldenburg2.str.redhat.com>
	 <479415e1-3aba-b456-fc67-0614fbd462a1@redhat.com>
	 <3ff867626ab263d456591509f57de0dc2ef99118.camel@redhat.com>
	 <87ef9e6zb4.fsf@oldenburg2.str.redhat.com>
	 <61a67a7893382e9db29fe108272da8f9b8924186.camel@redhat.com>
	 <87pnsy5d3z.fsf@oldenburg2.str.redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-SW-Source: 2019-01/txt/msg00331.txt.bz2

On Tue, 2019-01-15 at 13:17 +0100, Florian Weimer wrote:
> * Torvald Riegel:
> 
> > What I mean is that applications would have to want to use locks provided
> > by tbb, whether those are locks/mutexes that exist in tbb today or a new
> > API that would be added.
> > 
> > Put differently, I'm not optimistic about tbb being a good way to get
> > feedback.
> 
> Do you want to run existing workloads with a new mutex implementation?

We need to get there.

> Then we can't add new flags or change ABI in any way

Yes.

> and would have to
> use a tunable.  And to get feedback, we would have to make the new
> implementation the default, with a tunable to get back the old
> implementation.

I wouldn't be too concerned to getting back the old implementation, so
maybe we don't even need a tunable right now.  The old implementation is
just no spinning, so the cases where I can imagine the tunable to be useful
is either (1) experimentation to compare performance without using
different glibc's and (2) going back to old behavior in cases where we
really screwed up.  But how many users will have the time to investigate
(2), really?

Nobody should have to tune their spinlocks, or the back-off in mutexes. 
It's our duty to make sure this has good average-case performance.