This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] [PING] Optimize generic spinlock code and use C11 like atomic macros.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Wed, 31 May 2017 18:48:12 +0200
- Subject: Re: [PATCH 1/2] [PING] Optimize generic spinlock code and use C11 like atomic macros.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=triegel at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6FCBD72498
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6FCBD72498
- References: <1481905917-15654-1-git-send-email-stli@linux.vnet.ibm.com> <5857CF10.1060100@arm.com> <628f6311-239c-5eea-572c-c2acae6fcbee@linux.vnet.ibm.com> <1487017743.16322.80.camel@redhat.com> <60a34645-17e4-6693-1343-03c55b0c47ad@linux.vnet.ibm.com> <1487437038.20203.68.camel@redhat.com> <25ad863b-6f20-bfb7-95e6-3b04a2b3eee8@linux.vnet.ibm.com> <1487598702.20203.138.camel@redhat.com> <b57d3477-a041-7b06-82ac-6d2b6c6bb08c@linux.vnet.ibm.com> <1491487245.5374.161.camel@redhat.com> <09ae8ea7-4119-76c1-cd58-36cbdf587390@linux.vnet.ibm.com> <1491745903.5374.199.camel@redhat.com> <9c6a4c3a-4de9-1cd0-46e6-3a43151aed7d@linux.vnet.ibm.com> <f7fe729c-6dc0-7327-deba-01c685c65a3f@linux.vnet.ibm.com> <2607f4f9-768e-e1e6-2e2e-17696991813d@linux.vnet.ibm.com> <b6339fef-a7bd-8b40-c73f-99d0f21731f6@linux.vnet.ibm.com> <6d90fe07-19e1-8c05-d283-dd21f6902db3@linux.vnet.ibm.com> <1496128691.5890.973.camel@redhat.com> <f25d852a-fec9-c6a3-c781-437f94a06800@linux.vnet.ibm.com>
On Wed, 2017-05-31 at 10:29 +0200, Stefan Liebler wrote:
> On 05/30/2017 09:18 AM, Torvald Riegel wrote:
> > On Wed, 2017-05-10 at 15:00 +0200, Stefan Liebler wrote:
> >> On 05/03/2017 01:38 PM, Stefan Liebler wrote:
> >>> On 04/25/2017 08:46 AM, Stefan Liebler wrote:
> >>>> On 04/18/2017 03:09 PM, Stefan Liebler wrote:
> >>>>> On 04/10/2017 01:59 PM, Stefan Liebler wrote:
> >>>>>> On 04/09/2017 03:51 PM, Torvald Riegel wrote:
> >>>>>>> On Fri, 2017-04-07 at 18:22 +0200, Stefan Liebler wrote:
> >>>>>>>> @architecture maintainers:
> >>>>>>>> I've added defines of ATOMIC_EXCHANGE_USES_CAS in the architecture
> >>>>>>>> specific atomic-machine.h files.
> >>>>>>>> See comment in include/atomic.h:
> >>>>>>>> /* ATOMIC_EXCHANGE_USES_CAS is equal to 1 if atomic_exchange
> >>>>>>>> operations
> >>>>>>>> are implemented based on a CAS loop; otherwise, this is 0 and we
> >>>>>>>> assume
> >>>>>>>> that the atomic_exchange operations could provide better
> >>>>>>>> performance
> >>>>>>>> than a CAS loop. */
> >>>>>>>>
> >>>>>>>> Can review the definition to 0 or 1 in the atomic-machine.h file of
> >>>>>>>> your
> >>>>>>>> architecture, please?
> >>>>>
> >>>>>
> >>>>> PING
> >>>>>
> >>>> PING
> >>>
> >>> PING
> >>
> >> PING
> >>
> >> @Torvald:
> >> I'm not sure if we will get answers from everybody.
> >> What do you propose how to proceed with the definitions of
> >> ATOMIC_EXCHANGE_USES_CAS?
> >
> > Which archs are still missing? If maintainers don't reply, I suggest we
> > do our best to figure out what's the case for each missing arch, and add
> > a note that it should be checked eventually (eg, /* XXX Is this actually
> > correct? */) to the code, and then commit. Please CC: me on such a
> > patch, so I can have a last look at it.
> >
>
> We are sure for these archs:
> -aarch64: #define ATOMIC_EXCHANGE_USES_CAS 0
> -i386/x86: #define ATOMIC_EXCHANGE_USES_CAS 0
> -mips: #define ATOMIC_EXCHANGE_USES_CAS 0/1
> -powerpc: #define ATOMIC_EXCHANGE_USES_CAS 1
> -s390: #define ATOMIC_EXCHANGE_USES_CAS 1
> -tile: #define ATOMIC_EXCHANGE_USES_CAS 0
>
> Nobody answered for these archs:
> -alpha: #define ATOMIC_EXCHANGE_USES_CAS 1
> -arm: #define ATOMIC_EXCHANGE_USES_CAS 1
> -hppa: #define ATOMIC_EXCHANGE_USES_CAS 1
> -ia64: #define ATOMIC_EXCHANGE_USES_CAS 0
> -m68k: #define ATOMIC_EXCHANGE_USES_CAS 1
> -microblaze: #define ATOMIC_EXCHANGE_USES_CAS 1
> -nios2: #define ATOMIC_EXCHANGE_USES_CAS 1
> -sh: #define ATOMIC_EXCHANGE_USES_CAS 1
> -sparc: #define ATOMIC_EXCHANGE_USES_CAS 1
Joseph, can you clarify for arm?
> In the two of three sparc files ...
> ./sysdeps/sparc/sparc64/atomic-machine.h
> ./sysdeps/sparc/sparc32/sparcv9/atomic-machine.h
> ... there is the swap instruction in macro atomic_exchange_acq
> for 4 bytes. Other sizes are aborted or done by CAS.
> Shall we use #define ATOMIC_EXCHANGE_USES_CAS 0 here?
I suggest we let the sparc maintainer take care of that (though we could
set it to 0 for sparc32 I guess).
>
> I've attached the current version with
> /* XXX Is this actually correct? */
> for all architecture for which we didn't get an answer.
>
> The second patch "S390: Use generic spinlock code." remains the same.
I'd wait for a few more days to give Joseph time to respond, and then
commit if there are no objections or further input. I think maintainers
had enough time to comment, and you pinged them often enough already.
Thanks for being patient! :)