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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC086C7EE30 for ; Wed, 25 Jun 2025 08:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 708BC6B00B0; Wed, 25 Jun 2025 04:52:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B85B6B00B3; Wed, 25 Jun 2025 04:52:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F5B86B00B4; Wed, 25 Jun 2025 04:52:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4A6346B00B0 for ; Wed, 25 Jun 2025 04:52:17 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1F4AA1D9AA1 for ; Wed, 25 Jun 2025 08:52:17 +0000 (UTC) X-FDA: 83593306314.12.0E2A666 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id DB95E1C000B for ; Wed, 25 Jun 2025 08:52:14 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="qdhhzZ/l" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750841535; a=rsa-sha256; cv=none; b=mq3uW3Fu83jcVkQehL46hLlxz946zZJZ0QT2eYu4J/pp9T2gnAE0sMi9pG48a0hC6DsEVM 8CJJUh6+mkXDv6FW9y7bZ9QvUH2Lwmypn7Kc2zFYsjJ7p3oAvxHiP4wYcc9xB32SWAVc5H a8EbG70pW61hYetbuNE9BjIzR9OASVM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="qdhhzZ/l"; spf=none (imf20.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750841535; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kuB6DJokf+kOHeXrbarpBOCXQ2R6TXTfr6dB5Ad6/3o=; b=m+i7LCK3g/ydlpSHgFngUsOh3l4BjnzQqtIcpCt54FfHoSI9BLCSaPoaQQ+WtQZZ3p0IMw kyLoARXgRCAiaz20VXd4+wD9jrvcLFSuTkEChf0yIM4T0T/3en2XXukglp0wQrrX9fiiq3 Oh91Ajmn0GAkuNiTOoqrNLZp4Ke2/oc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=kuB6DJokf+kOHeXrbarpBOCXQ2R6TXTfr6dB5Ad6/3o=; b=qdhhzZ/loUJj4/x5n1ZsfY53Nz Fntzcq+G7Y/WZyznoGpiZ7N4mKDED4CDh/WdAgmi3O+iNUt7rgLHT3tHo5gFYzOj9lYVZpAm+ZnrP G05fPGu8gkCAHZvkBTPR4I0oA+PUFsXB3oApC0I2V0hRhpNPY/5aMfB5xm29ewdmMfBHjM4tJbnLw QxfeCT0jEuuQkqMrvyWdmXRe5fVFGCMyj45ECw6qFjSmQaMeCSy45iIgODWENrFchbf8SeEcFryJY JJw69p01O0rNbx5o/QkCzhrKPISMe+xwHd1X/oTD9eXtsti2Bp90yL3XCAYmh7O5IOyLtZ1+D0yLZ oBU97CHw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uULrR-00000008vs3-11Ci; Wed, 25 Jun 2025 08:52:05 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C97B3308983; Wed, 25 Jun 2025 10:52:04 +0200 (CEST) Date: Wed, 25 Jun 2025 10:52:04 +0200 From: Peter Zijlstra To: Jonathan Cameron Cc: Catalin Marinas , james.morse@arm.com, linux-cxl@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, Will Deacon , Dan Williams , Davidlohr Bueso , Yicong Yang , linuxarm@huawei.com, Yushan Wang , Lorenzo Pieralisi , Mark Rutland , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, H Peter Anvin , Andy Lutomirski Subject: Re: [PATCH v2 0/8] Cache coherency management subsystem Message-ID: <20250625085204.GC1613200@noisy.programming.kicks-ass.net> References: <20250624154805.66985-1-Jonathan.Cameron@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250624154805.66985-1-Jonathan.Cameron@huawei.com> X-Stat-Signature: sxzoekpbj3mo8wejuacuzw175szgpt9i X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DB95E1C000B X-Rspam-User: X-HE-Tag: 1750841534-67271 X-HE-Meta: U2FsdGVkX194FGSWYoVDa8xhhH9dDVE8j4r1fBjg/h4N2F9RVGrBAB42HBdNCmUd63DgonU9nItXr5Ek/9hG8Zpd6btxLOdhS5RfaYmxuIcvBLhw8yHsYgF5TUHrAANdnyH2yk6y/U0b5nPcdlpz5dysjA8l9YCDoevFgqCJWSlE/5OuuK+J7y8plX+we/5W09EOAFz760PCK3VYoXMgv8FJ694R2DHQQW+Ia2w27n+gL2bQqHYkT6ew9r5vmu9wD29DosmVEtEzyQzbK14Oa7gJLjZFzkEEziMbiOc7xPGhytJQZQ5NHyAt0SJK/bAD6Q6s1vin+JKKXrmDzFC8P5KeUiwAodtlf/z6Sq9Kfmi2VpG1ZUeAF9psKwONHhbXNTjUHj+sZVyNg5Sk8+maMRffDuR4vXL6yPn0fanJsTYsVLUOJpVTXgapcDVW+2s0zsraSXZX2cT+g8w//MaeJt5NL4BINCyTxPYSHFvfwVgJ7b64+VRqXv/oi73tJrjzQxYjJsaNZKGDP9H/kt9lZroRDsZ1K3eWbsUKlh8HKeQQW7JI8FAWa1btpPysGJPRoPeY4qjRZ/g7K6Opa6zjpKaiFL5OVRdz6agV+BinaVVbGwWm9h1qJV/pp6+bgXKbOgpCbh068Re+UMD5gn54Q8vyVh6/CVun/InqwvN7qbI+Ac1CZsdPQ6Tx8NJKQLWfCKfcx921eI74sZeziZ00fJkOOgzHaIqhSNr0kurPV/a7LMCaU4Pa8ldx7lYRqFmr/03b+m8cX1zf0XbDUVZy8DSxDy5JP8YQi2QAsmxqRmXqxGBBPIz2s74zJy7XX9H5Ltu8zXu3lMeaVu4Y7THon2ILGJ+yRu4Nlv9uIm65gzWfku/0QjvalQtxaApmaR9+NziZsfNhNfJgN8HuKSIKDA04l5YyYqWnGMzkX2QrBCaFJAS9Hx/0WNnzSP0mD9W+wuDSn0zIjEq3J96x0bT l87z/VWX S3NoVROmzL6luekxYvWgX5HH2OojAVQhy5i8V9wh0eCjZUJlxjjnUijLl0//Keqb5ffV2FNqWziLZ+zTdnFXHSu+HUFUUBCiKlYh+3YYG6SoMmhaA3MVgac+R9th2On8KRW2g5qX48O6lKnA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 24, 2025 at 04:47:56PM +0100, Jonathan Cameron wrote: > On x86 there is the much loved WBINVD instruction that causes a write back > and invalidate of all caches in the system. It is expensive but it is Expensive is not the only problem. It actively interferes with things like Cache-Allocation-Technology (RDT-CAT for the intel folks). Doing WBINVD utterly destroys the cache subsystem for everybody on the machine. > necessary in a few corner cases. Don't we have things like CLFLUSH/CLFLUSHOPT/CLWB exactly so that we can avoid doing dumb things like WBINVD ?!? > These are cases where the contents of > Physical Memory may change without any writes from the host. Whilst there > are a few reasons this might happen, the one I care about here is when > we are adding or removing mappings on CXL. So typically going from > there being actual memory at a host Physical Address to nothing there > (reads as zero, writes dropped) or visa-versa. > The > thing that makes it very hard to handle with CPU flushes is that the > instructions are normally VA based and not guaranteed to reach beyond > the Point of Coherence or similar. You might be able to (ab)use > various flush operations intended to ensure persistence memory but > in general they don't work either. Urgh so this. Dan, Dave, are we getting new instructions to deal with this? I'm really not keen on having WBINVD in active use.