Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp36682257rwd; Tue, 11 Jul 2023 04:29:03 -0700 (PDT) X-Google-Smtp-Source: APBJJlFSei8pHd+6FXAw0tiotf5X0+suqiy3tsTrMCXcFkWZumlVi7qeyZ9Ta70mqqED+pphCTkW X-Received: by 2002:a17:902:ce81:b0:1b8:3e15:40e8 with SMTP id f1-20020a170902ce8100b001b83e1540e8mr418184plg.56.1689074942767; Tue, 11 Jul 2023 04:29:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689074942; cv=none; d=google.com; s=arc-20160816; b=ux3om2gyNGJjTpRJjALRbkcQyhT28PRoXO5FvPpVdsFIoeGaRvERH8o3peKOIOKSBs /Dh5ofXDgDOsSsjjP0LfaAA7peUrwN8eSiBbFeCWP+fWPR57c6/zFB3xrast4xTuu5ZQ EtkXIVlPYM/GjcKtN5NSKNyswwKSRk2827W1KSL9f2EAyJqXEL6gouh0ZmmZ7aFzBnQQ cdaT/xTG7lPd6XZvd7RU7/raVxMaXkJ/IKrM2ZKUdbn0jzhXFzmbt3AKEpHB2SoQjf4a P7FwEv1EB7p7QtQd9c+urmoL0zuZgGbMIcLCibus2LILo33mqj4Tao3DLpkdR7lSR+6x IqJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=cUyNgU33h3MY0tbUMjLo9nHBJGV+GwEPSoKc44XkN/k=; fh=Ht19k9snRbrmLqsZcuX2vwhmTJj5fl96D9ORltk2qFo=; b=egaDlh77o9vhdgm8ZYK4sGdp1yitTjCY8+HebkZjmLNLMScsk5QaLK737OMzI+zsDT MJDjxGjN777l3auV5ZJk52+zEEjAmav+Xbd83OBqbtdvy/q6ndO7+YrRBAtoOeE5857w GzhQa2fsgQ7orPcM6cIgGDi/5xQg7wz/oAO1usz39/zD87Gb272YO9/8S8zlm+biJELD 03CYiZ2T0XJnwqZp+GMymDpkheQIuf+mCjXZpcIBjQEkUXkD+HtP+xHAPym1laadO0+S 1m+1TWtRj0Q/cQwI3A7OC8PbGYI0vw8MnkyVSkPiGxcnBiv5y+sk5f3y6tD1dFmK/Caa LN0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fsBVrD0V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x15-20020a170902ec8f00b001b8920564cesi1523175plg.17.2023.07.11.04.28.51; Tue, 11 Jul 2023 04:29:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fsBVrD0V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230292AbjGKKZU (ORCPT + 99 others); Tue, 11 Jul 2023 06:25:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230439AbjGKKZT (ORCPT ); Tue, 11 Jul 2023 06:25:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77A5D136; Tue, 11 Jul 2023 03:25:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 85AF26145D; Tue, 11 Jul 2023 10:25:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6F8BC433C8; Tue, 11 Jul 2023 10:25:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689071116; bh=TOqlJUFHaJBKmQf2cGYAl73/mk9Gcc2SsywmsziYi5I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fsBVrD0VftvJCAMA4m23UBTa2QMEpfh8VPytwt6VbmLtjVMZbDL22pwmxIYgsGvvd KPPBk+sSC3gr1EcGohswi97s3Kwup2+aZeaps9CmTPeEGTmI+r6yF3F+yDHo0PrW++ xeWdIEkQJuWPJf+hbT+SmYC5SzKWwTiMbfnzkEd7z7JwVtNiK1PRhe8Nm0RporIEc/ 6rmAZE8BYet39GdehoVcfD+RuKGLMESsIkPYCdLZScxU/b1xOwOWQnz1qo7JxEWo7M AgFTtNtXCrrKNgvx/dUdbFooaddoZEhBBnbIcgV+7y6e5hBswhaIP2IudW+48ZpQbR dPfGmovBooH7A== Date: Tue, 11 Jul 2023 11:25:11 +0100 From: Will Deacon To: "Aiqun(Maria) Yu" Cc: corbet@lwn.net, catalin.marinas@arm.com, maz@kernel.org, quic_pkondeti@quicinc.com, quic_kaushalk@quicinc.com, quic_satyap@quicinc.com, quic_shashim@quicinc.com, quic_songxue@quicinc.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64: Add the arm64.nolse_atomics command line option Message-ID: <20230711102510.GA1809@willie-the-truck> References: <20230710055955.36551-1-quic_aiquny@quicinc.com> <20230710093751.GC32673@willie-the-truck> <5cf15f85-0397-96f7-4110-13494551b53b@quicinc.com> <20230711082226.GA1554@willie-the-truck> <84f0994a-26de-c20a-a32f-ec8fe41df3a3@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84f0994a-26de-c20a-a32f-ec8fe41df3a3@quicinc.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 11, 2023 at 06:15:49PM +0800, Aiqun(Maria) Yu wrote: > On 7/11/2023 4:22 PM, Will Deacon wrote: > > On Tue, Jul 11, 2023 at 12:02:22PM +0800, Aiqun(Maria) Yu wrote: > > > On 7/10/2023 5:37 PM, Will Deacon wrote: > > > > On Mon, Jul 10, 2023 at 01:59:55PM +0800, Maria Yu wrote: > > > > > In order to be able to disable lse_atomic even if cpu > > > > > support it, most likely because of memory controller > > > > > cannot deal with the lse atomic instructions, use a > > > > > new idreg override to deal with it. > > > > > > > > This should not be a problem for cacheable memory though, right? > > > > > > > > Given that Linux does not issue atomic operations to non-cacheable mappings, > > > > I'm struggling to see why there's a problem here. > > > > > > The lse atomic operation can be issued on non-cacheable mappings as well. > > > Even if it is cached data, with different CPUECTLR_EL1 setting, it can also > > > do far lse atomic operations. > > > > Please can you point me to the place in the kernel sources where this > > happens? The architecture doesn't guarantee that atomics to non-cacheable > > mappings will work, see "B2.2.6 Possible implementation restrictions on > > using atomic instructions". Linux, therefore, doesn't issue atomics > > to non-cacheable memory. > > We encounter the issue on third party kernel modules and third party apps > instead of linux kernel itself. Great, so there's nothing to do in the kernel then! The third party code needs to be modified not to use atomic instructions with non-cacheable mappings. No need to involve us with that. > This is a tradeoff of performance and stability. Per my understanding, > options can be used to enable the lse_atomic to have the most performance > cared system, and disable the lse_atomic by stability cared most system. Where do livelock and starvation fit in with "stability"? Disabling LSE atomics for things like qspinlock and the scheduler just because of some badly written third-party code isn't much of a tradeoff. Will