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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS 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 00A0CC433E0 for ; Wed, 31 Mar 2021 04:20:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B3E63619D9 for ; Wed, 31 Mar 2021 04:20:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230073AbhCaETd (ORCPT ); Wed, 31 Mar 2021 00:19:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:58514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229852AbhCaETK (ORCPT ); Wed, 31 Mar 2021 00:19:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 703E8619DA; Wed, 31 Mar 2021 04:19:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617164349; bh=0XKwss4Hof3X25r6bjrJJVKM4RoMnNg6Pao3M+Ls9mU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EmuXNN/8sS0Dbso4e+1fSvCIBEJnh+7frW86Bh5XC1AUpZmbWTLOztPmx9K3uJXOM XBjKOBGQRd5WESSU341/Fj2LGYqIqANNSNcbbP4Iz8pbzppxUGPJCzBEVO2mCLSif5 sFMyg0u7/FAWyEc0Rmc/nL2cI3ttI5QT0+3+GzQdaLGDZjeuSNKuLCoGWk4Q2Bew0a xXA9RdzeIfZo0kowdTCLO8qKjGyUebWKh3tPaPok32BdzmvKg/gN8IWaL7gQq+1ZCX LmPqiyI+grbC3WBT/AE1TNi1A2p9q73bVbaM6r94gNfERYwzTn4jNvcEzvmx4stWDn 7thLSj1O4gduQ== Received: by mail-lf1-f50.google.com with SMTP id d13so6112689lfg.7; Tue, 30 Mar 2021 21:19:09 -0700 (PDT) X-Gm-Message-State: AOAM5331z8wbONkLk2WtqB1Aq1FwAXX/y6BzQFOoBAwewNK7oTUK2XOX eLSyzVRkdIi7LiJRmhwPk25TZMlHXD5vYs/u0ss= X-Google-Smtp-Source: ABdhPJx+ii4cISAbi0jdeMRF01vf8KEr9bLID6axyIdKr+61ZHMDTxRv3u6V5SiTCLty4Ct/I0NqsI5Om8KadMxQvUE= X-Received: by 2002:a05:6512:ba2:: with SMTP id b34mr970839lfv.24.1617164347742; Tue, 30 Mar 2021 21:19:07 -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: Guo Ren Date: Wed, 31 Mar 2021 12:18:56 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 To: Arnd Bergmann 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" Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote: > > 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 Thx for the nice explanation: - RsrvNonEventual - depends on software fall-back mechanisms, and just I'm worried about. - RsrvEventual - HW would provide the eventual success guarantee. > > > [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. Does that mean we should prevent using LR/SC (if RsrvNonEventual)? -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/