From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8278CC433C1 for ; Tue, 30 Mar 2021 07:13:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4908A619AA for ; Tue, 30 Mar 2021 07:13:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231138AbhC3HM2 (ORCPT ); Tue, 30 Mar 2021 03:12:28 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:36421 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231124AbhC3HMI (ORCPT ); Tue, 30 Mar 2021 03:12:08 -0400 Received: from mail-ot1-f52.google.com ([209.85.210.52]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1N2m3G-1ld3Gc1HJM-0138q1; Tue, 30 Mar 2021 09:12:06 +0200 Received: by mail-ot1-f52.google.com with SMTP id t23-20020a0568301e37b02901b65ab30024so14724361otr.4; Tue, 30 Mar 2021 00:12:05 -0700 (PDT) X-Gm-Message-State: AOAM5312LOB1OQ+LBYTu/wZBy3A6sVxvfZeTukLGeMj1HbbkPnhNY4Ql x5FkXvVSQHkQlRU8MrwBcbzAzxmnXIn1J3BMayM= X-Google-Smtp-Source: ABdhPJxrmSwVSZDP48DP+ikIRCBts1IlD1OfpYYF4tYk3/WxR/8UdJvAQaT3CYFMV6J7JYaeLxkX8qHf4eLpRGNv27Q= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr26882538otq.251.1617088324803; Tue, 30 Mar 2021 00:12:04 -0700 (PDT) MIME-Version: 1.0 References: <1616868399-82848-1-git-send-email-guoren@kernel.org> <1616868399-82848-4-git-send-email-guoren@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Tue, 30 Mar 2021 09:11:50 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 To: Guo Ren Cc: Peter Zijlstra , linux-riscv , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-arch , Guo Ren , Will Deacon , Ingo Molnar , Waiman Long , Anup Patel , Sebastian Andrzej Siewior Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:dAc5/IYR3tPhlPw55hBn68XavOmrbOPoV9eDq5ASekeKo4KXdBt zG1nND9akWPe1zCpdB3g2XyNcD4NsEvHJIMPgk/mRumNTnCkQt1RQoMiYkNknXjTHkEOtSN IAKcvC5wsIideRGGjimmJ/lfGh9/wuWpx/XXQQJd62TauGO20yCg+FqVkcAj/VAYGrJg4My KAEK8nC3sztcuJUbOpvTw== X-UI-Out-Filterresults: notjunk:1;V03:K0:2Ml0stvVTjU=:kt/2nob/5Op9UcVdXbiJ1B +CiIPVdQxeKZ9NN7g3MGau8DSrXSHN8K433EbhL0VRMFnPHHso0rmdopG2y6MzhgcGKzU6IKO AwInUVew1aIPfFigXoBbj0Hc2ckCA5VSs+WWzA7U7WMx9lE4DwzzpQJr8WRGhlmV54volstgG /d3jb2nLe4HS+yOPTLS9dxyM0s3BEQIV8kHdcQpiFGQ0ltoggLeTVspxm9ZksMEuFJp7RPN9A vmUldroy1LIE5rU6ppUKTI4U4BAlqeSxrQSFyGPFujb1PAlhUYvH6ycqMKgYr28ZS3uynl5mU xCuRIFl1pQTDamqXonXegn6O15R9wrgp7xzJR7Wv3hEUp++JuoHrrPG7ysvglxbb6+0zTyVg9 dV5cTXI0iTfu+9W92s7ywrJLA3QXx38j3hkx58m10gY5KSY6Mit1DXkGM+jo9PZafxUCfVIAh KTPmigP+pbqNE8A4mX4i5q3Zf3uVZQFU3EA2njg63ToU029Ghwr7pDYBQH+gpvPKz0iaHZGsK V2cSLoK6g9vzoS7ZCHc8o1p+rTqfo59K2JztfZ6iHFlHsELaWp5JDNToR+Lp/9s9IvM/LOIjk zXkONm/ElG2sb+t6SVf+uyLG+1nUyvY+8X Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote: > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote: > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote: > > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra wrote: > > > > > > > > What's the architectural guarantee on LL/SC progress for RISC-V ? > > > > "When LR/SC is used for memory locations marked RsrvNonEventual, > > software should provide alternative fall-back mechanisms used when > > lack of progress is detected." > > > > My reading of this is that if the example you tried stalls, then either > > the PMA is not RsrvEventual, and it is wrong to rely on ll/sc on this, > > or that the PMA is marked RsrvEventual but the implementation is > > buggy. > > Yes, PMA just defines physical memory region attributes, But in our > processor, when MMU is enabled (satp's value register > 2) in s-mode, > it will look at our custom PTE's attributes BIT(63) ref [1]: > > PTE format: > | 63 | 62 | 61 | 60 | 59 | 58-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > SO C B SH SE RSW D A G U X W R V > ^ ^ ^ ^ ^ > BIT(63): SO - Strong Order > BIT(62): C - Cacheable > BIT(61): B - Bufferable > BIT(60): SH - Shareable > BIT(59): SE - Security > > So the memory also could be RsrvNone/RsrvEventual. I was not talking about RsrvNone, which would clearly mean that you cannot use lr/sc at all (trap would trap, right?), but "RsrvNonEventual", which would explain the behavior you described in an earlier reply: | u32 a = 0x55aa66bb; | u16 *ptr = &a; | | CPU0 CPU1 | ========= ========= | xchg16(ptr, new) while(1) | WRITE_ONCE(*(ptr + 1), x); | | When we use lr.w/sc.w implement xchg16, it'll cause CPU0 deadlock. As I understand, this example must not cause a deadlock on a compliant hardware implementation when the underlying memory has RsrvEventual behavior, but could deadlock in case of RsrvNonEventual > [1] https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc52afd0fcbf88 > > > > > It also seems that the current "amoswap" based implementation > > would be reliable independent of RsrvEventual/RsrvNonEventual. > > Yes, the hardware implementation of AMO could be different from LR/SC. > AMO could use ACE snoop holding to lock the bus in hw coherency > design, but LR/SC uses an exclusive monitor without locking the bus. > > RISC-V hasn't CAS instructions, and it uses LR/SC for cmpxchg. I don't > think LR/SC would be slower than CAS, and CAS is just good for code > size. What I meant here is that the current spinlock uses a simple amoswap, which presumably does not suffer from the lack of forward process you described. Arnd