From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB5E315E88 for ; Thu, 11 Apr 2024 18:43:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=212.63.210.85 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712861027; cv=none; b=TVZNE49AqQmQm3BtYjJenEjWl4Gb0bKzZfgH5jh8jXpwlSKKy7TODV2ZHua+6AEXxqS21LEQ9tSErQOf2uY8uD6h1VedF+B7ghvBwkAWnvtJA8plppWzuaWjzRPmB3O4UjbDTEESyeLlH05/5wMrCaTa+dD95pO2VH1FMAOZ8jM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712861027; c=relaxed/simple; bh=a3JvUEhgYK+th3NCl2xP4vXg/lpXBSLqgc8nLV72rpU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=nmBr969aRNWhXgNzpLhMIlw2aEw9BDl78QFRs+VW5qP6+yHKgd/zCSYICYrfPdweqXgACcZ6Hekz0CAarpQ4OwWAaaeYY67Ezm41PTX0pi+aThsWsDwSZgftiWrtQWaMzIcD6xE7498Q2OI7pPBtcmOYqbqZpxr0JC2Vo+M/SW8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=marcan.st; spf=pass smtp.mailfrom=marcan.st; dkim=pass (2048-bit key) header.d=marcan.st header.i=@marcan.st header.b=SxfDLmbn; arc=none smtp.client-ip=212.63.210.85 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=marcan.st Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=marcan.st Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=marcan.st header.i=@marcan.st header.b="SxfDLmbn" Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 162A24269B; Thu, 11 Apr 2024 18:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1712861022; bh=a3JvUEhgYK+th3NCl2xP4vXg/lpXBSLqgc8nLV72rpU=; h=Date:Subject:From:To:Cc:References:In-Reply-To; b=SxfDLmbn4C0FHradf1Xvj6eoisfqZiNOMVhNdxdgHo1NXlIB/dbWS/wzj7bn6DGW/ NTt6SGUM8bZrQe1tL93LuYhRW67a4Imuzypj7Kyz8L5KRHP0KQqoTXOLfWYVI7bvAe M+fdkh7Z1E0OnNt1boNhIk7u9FsTO0sAekynhELR0de5yFs2lr1xtmxYdeDa6pehzF LKJiq4QJpwlqoQ+p63rnkcUDDB/Lo/UPQrqmsa+qVuYvSLpezbl3c9OIl/YtYiEgD+ sOsykq2DUWdG71dSOs48cNQHSHF+9gaFcPhQ8Kyp0Uu/YkyzblwkZj7kL+KuaSH0MS TcEp9qwJBnqDw== Message-ID: Date: Fri, 12 Apr 2024 03:43:36 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model From: Hector Martin To: Will Deacon Cc: Catalin Marinas , Marc Zyngier , Mark Rutland , Zayd Qumsieh , Justin Lu , Ryan Houdek , Mark Brown , Ard Biesheuvel , Mateusz Guzik , Anshuman Khandual , Oliver Upton , Miguel Luis , Joey Gouly , Christoph Paasch , Kees Cook , Sami Tolvanen , Baoquan He , Joel Granados , Dawei Li , Andrew Morton , Florent Revest , David Hildenbrand , Stefan Roesch , Andy Chiu , Josh Triplett , Oleg Nesterov , Helge Deller , Zev Weiss , Ondrej Mosnacek , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Asahi Linux References: <20240411-tso-v1-0-754f11abfbff@marcan.st> <20240411132853.GA26481@willie-the-truck> <28ab55b3-e699-4487-b332-f1f20a6b22a1@marcan.st> Content-Language: en-US In-Reply-To: <28ab55b3-e699-4487-b332-f1f20a6b22a1@marcan.st> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2024/04/11 23:19, Hector Martin wrote: >> >> An alternative option is to go down the SPARC RMO route and just enable >> TSO statically (although presumably in the firmware) for Apple silicon. >> I'm assuming that has a performance impact for native code? > > Correct. We already have this as a bootloader option, but it is not > desirable. Plus, userspace code still needs a way to *discover* that TSO > is enabled for correctness, so it can automatically decide whether to > use stronger or weaker instructions. To add some numbers to this (I was just made aware of this paper): https://www.sra.uni-hannover.de/Publications/2023/tosting-arcs23/wrenger_23_arcs.pdf Using TSO globally has, on average, a 9% performance hit, so that is clearly off the table as a general solution. Meanwhile, more detailed microbenchmarks often show TSO as having better performance than outright using acquire/release instructions without TSO. Therefore, just giving up on TSO and using acq/rel semantics for emulators is also not an acceptable solution. Additionally, the general load/store instructions on ARM have more flexible addressing modes than the synchronizing ones, and since general x86 emulation requires *all* loads and stores to be like this in a non-TSO model (without much more complex/expensive program analysis to determine where this can be elided), the perf impact is definitely worse for emulation (e.g. stack accesses are affected) than for a microbenchmark where only the "target" test instructions are being modified. - Hector