From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89480 invoked by alias); 15 Jan 2019 04:47:36 -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 89469 invoked by uid 89); 15 Jan 2019 04:47:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FROM_EXCESS_BASE64,MIME_QP_LONG_LINE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.3.2 spammy=HContent-type:plain, HContent-type:charset, HContent-type:text, talked X-HELO: out0-146.mail.aliyun.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R961e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01454;MF=ling.ml@antfin.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---.Dln47qA_1547527623; User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 15 Jan 2019 04:47:00 -0000 Subject: Re: [PATCH] NUMA spinlock [BZ #23962] From: "=?UTF-8?B?6ams5YeMKOW9puWGmyk=?=" To: Torvald Riegel , Ma Ling , CC: , Wei Xiao Message-ID: References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local> <1c5330189c18781afec2db7b47158de2dea041b8.camel@redhat.com> In-Reply-To: <1c5330189c18781afec2db7b47158de2dea041b8.camel@redhat.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-SW-Source: 2019-01/txt/msg00324.txt.bz2 =EF=BB=BF=E5=9C=A8 2019/1/15 =E4=B8=8A=E5=8D=887:26=EF=BC=8C=E2=80=9CTorval= d Riegel=E2=80=9D =E5=86=99=E5=85=A5: On Wed, 2018-12-26 at 10:50 +0800, Ma Ling wrote: > 2. Critical Section Integration (CSI) > Essentially spinlock is similar to that one core complete critical > sections one by one. So when contention happen, the serialized works > are sent to the core who is the lock owner and responsible to execute > them, that can save much time and power, because all shared data are > located in private cache of the lock owner. =20=20=20=20 I agree that this can improve performance because of potentially both increasing data locality for the critical sections themselves and decreasing contention in the lock. However, this will mess with thread- local storage and assumptions about what OS thread a critical section r= uns on. Ling: yes, we have to consider it when applying numa spinlock.=20=20 Maybe it's better to first experiment with this change in semantics in = C++; ISO C++ Study Group 1 on parallelism and concurrency is much deeper into this topic than the glibc community is. This isn't really a typical lo= ck anymore when you do that, but rather a special kind of execution service for small functions; the study group has talked about executors that execute in guaranteed sequential fashion. Ling: thanks for your suggestion, we would like to think about it seriousl= y.=20=20