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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 71297C433DB for ; Wed, 31 Mar 2021 06:45:19 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 14887619C1 for ; Wed, 31 Mar 2021 06:45:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14887619C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mSwOQ1q34f9+jdcX2L9G8Xngl1ooIqFdVvzFyKJ/FvE=; b=MONb1pEdDT6VC3LNE5pvtU60N n3CiClt4aqf/hn0tqcOlEzyejIZ3Bm+KYrNsLYSUFzjk4EvjVfBONdL7F8tAdaeu5K6jcwYHi5srS 0mPPw+8IA2JlzqcTEl6IPFjkiv7tDB/hOzdT2PU2xi5+biZOeQM7qwe4G2dZxnSyINB0mizRJOWLI SJZPFhafjTPPcCSN6FCiRqD1+3LFEd1L7S5Lv74Ks2P8/u7VMIHr3VgAcL/8CX+O1rzvQUeFAUfVD HZvYAUAmOM5wS3vel9FD0lWL9JmZyNRwEC7c1dCYGW5RDe/vzKjjrLEXaX3/HKMUEL2sGwSDU5n6Q UuGm3FcPQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lRUb9-005g1x-2m; Wed, 31 Mar 2021 06:45:03 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lRUb2-005g0l-O1 for linux-riscv@lists.infradead.org; Wed, 31 Mar 2021 06:44:59 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C788B619D3 for ; Wed, 31 Mar 2021 06:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617173093; bh=RCtIwtDpANVEhOwxfHGQkphllx8RKXVlHbyBxFGWDK4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=g44+W5BgDfH0Mjud17uzJVuImiF0tl5u9sfPtLjbXhtm20ORWA0v8fwCgdlWIpMMu OfnXztDZwRdq79+Gz01hfvlHohRYt6oKuY+FXAtiZLnrgzFBtYM1MbadNRK73JSUOB hAlAkXlzDsz59wy3xxja7mC8LkquZtM17TYYr7L2cV8RsdmmeoY55K1CnktQ80tyDJ 2fD/v2SOK6bfbyouEaELgfG8JJQ+PvIS6TUlMG53YSohQvDSRKbPqLE2C/zH9hiOb7 CGhhM1vVL68ilTdg/RkuxgSPd3l3ydh6jfoCllXj6XM7U7d+rt12tAmraeffVYchnk y8IZY8j/Y4ZJA== Received: by mail-lf1-f48.google.com with SMTP id i26so27451893lfl.1 for ; Tue, 30 Mar 2021 23:44:52 -0700 (PDT) X-Gm-Message-State: AOAM531xrir/9qytHKbc0iqZx6HN3zKp9RBohs04nqs7vins86qbtIsi /0g40Umc4h1C+SgHTo5j0NBdOCOxLFjbcDzSSF4= X-Google-Smtp-Source: ABdhPJxWYKb5vHi3klerXBGqzxQaEaOsaVtBWtfmdufISdS1fHhvHXRHt+Ss9wnIFsGhtXF8Im+2yqjIQpsIkJolMPg= X-Received: by 2002:a05:6512:3709:: with SMTP id z9mr1231142lfr.557.1617173090981; Tue, 30 Mar 2021 23:44:50 -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 14:44:39 +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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210331_074457_861529_9D5CE522 X-CRM114-Status: GOOD ( 38.55 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Hi Arnd On Wed, Mar 31, 2021 at 12:18 PM Guo Ren wrote: > > 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. In riscv-spec 8.3 Eventual Success of Store-Conditional Instructions I found: "As a consequence of the eventuality guarantee, if some harts in an execution environment are executing constrained LR/SC loops, and no other harts or devices in the execution environment execute an unconditional store or AMO to that reservation set, then at least one hart will eventually exit its constrained LR/SC loop. *** By contrast, if other harts or devices continue to write to that reservation set, it ***is not guaranteed*** that any hart will exit its LR/SC loop.*** " Seems RsrvEventual couldn't solve the code's problem I've mentioned. > > > > > > [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/ -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv