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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9BF1DEB64D9 for ; Mon, 10 Jul 2023 09:18:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GNqTD17E/ui9Qab0Gc4YyEFJu5/S4DYiaHtOO9Im+iY=; b=DY91iBTu+Pg4/A FD1/ZHa85/h4coHBKeqr3mwyN57A7DKSo2tHQucxJBIWWds17oLUZ35SnRDJXvBTu+H31fWu8tTXX xjj1Kne2iPu8DRNzuwO53iu/gSCSr+ImiEawIB6IGiUzcnCAYJMx8TteQDY9WufIinxx8zvwU0Y5T yTznALijbTtQT97EgLNKnxFmDufVZRP4+Y9PUtkKncapDYkpNeadeMoImOM/d+AEeMBAK38UwbmTc pi1sqwSxNpcUC71S1fBKfVFddn2+XcC8nqe9mn2Swa0o3eLnEttuijG+lUcugX+m1PS+5SN21apIP lJuT9Y20cWaHDFf3YwCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qIn1p-00Az15-0H; Mon, 10 Jul 2023 09:17:57 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qIn1m-00AyzU-1C for linux-arm-kernel@lists.infradead.org; Mon, 10 Jul 2023 09:17:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688980670; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xLw+AO5WmDxQ3csKYjLPHy6exsc/2+oE8SjJWQaEdus=; b=K5q81tWQtIiGW0RWv+SkyH1sPkScIQ/3oQlr28O8Mr1C2sdWZRQvoUHiUTmNBfTXRqg7e/ XO6hLTLZ+a/J1+9+be8cK0t/xviBqg2btfezQ6ESBAh8oONPgH1orJJFBDEXXS+gB4WtHv Oj5JcFiVEQEmzLaDKxT9BKpe7fXPZS0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-aJmEuh4mNi2VuyMb5aFzSg-1; Mon, 10 Jul 2023 05:17:49 -0400 X-MC-Unique: aJmEuh4mNi2VuyMb5aFzSg-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-2f2981b8364so2437296f8f.1 for ; Mon, 10 Jul 2023 02:17:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688980668; x=1691572668; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xLw+AO5WmDxQ3csKYjLPHy6exsc/2+oE8SjJWQaEdus=; b=BnKYWFxoWZuWV7+z6dLfp6TcBUQhwKBLIOC03IeLzP5TZf/uzcysC3hIjWT1GeKOTT 5Om9gVTCV3wGnJkbTnDWwQS8IOjmEnMIvz+YT6Y5BCVLWXqGhYPZi80ai1U6brHik85M r/qOeoQy8WuCmQBRgU2o8u5JlHybhuQjLuKtOb0Nr+zRSrt/k5eqJu/BEunTMDtHN789 PmLTOe39T+AgaFB9CrVcRo7pD+hgOmQatKPetMsUoJu38tdOuplu67QUGIIGyBV0dLLx K87+pli5/H+TBQ5WJfu83YYp1LyFl0a8O+219Emmq6ySmS0csm/5pMNdeOeFrRbTqrkp Ftqw== X-Gm-Message-State: ABy/qLYlvVtmKvZtH5mhqEgGORPLnGEQH7Nf12X3BzoiirJh3/CoZ9g0 cEt4vRPIoajKWjl20Kbz5xLlEf/4sdJIe67jwdDjGatRPPBahV6mg5xO+47NxOLgq3bkr3ejazr VFlt0xIQ4ewNGAmMa6gZ+RIYF6Cm0arZ2NiOlPKQvEhY= X-Received: by 2002:adf:ef0e:0:b0:314:1e47:8bc2 with SMTP id e14-20020adfef0e000000b003141e478bc2mr12119041wro.0.1688980667911; Mon, 10 Jul 2023 02:17:47 -0700 (PDT) X-Google-Smtp-Source: APBJJlHTFJ4PQPXaxRY5On96/da4yfNKA43m9lQ9LRs+zzyTXuxkHBt1raaEcxgqmC0aE2VzceMCOQ== X-Received: by 2002:adf:ef0e:0:b0:314:1e47:8bc2 with SMTP id e14-20020adfef0e000000b003141e478bc2mr12119020wro.0.1688980667594; Mon, 10 Jul 2023 02:17:47 -0700 (PDT) Received: from ?IPV6:2003:cb:c738:7500:b60f:a446:46f6:5acf? (p200300cbc7387500b60fa44646f65acf.dip0.t-ipconnect.de. [2003:cb:c738:7500:b60f:a446:46f6:5acf]) by smtp.gmail.com with ESMTPSA id l12-20020adfe58c000000b0031590317c26sm5545593wrm.61.2023.07.10.02.17.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jul 2023 02:17:47 -0700 (PDT) Message-ID: <3a66672b-6378-a8e6-a329-16f65201fe92@redhat.com> Date: Mon, 10 Jul 2023 11:17:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC 0/4] arm64/mm: Clean up pte_dirty() state management To: Anshuman Khandual , linux-arm-kernel@lists.infradead.org Cc: Catalin Marinas , Will Deacon , Ryan Roberts , Mark Rutland , Andrew Morton , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <20230707053331.510041-1-anshuman.khandual@arm.com> <60732ee3-f1c5-3534-29fc-783ec48f2c92@arm.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <60732ee3-f1c5-3534-29fc-783ec48f2c92@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230710_021754_496229_EE91BD3F X-CRM114-Status: GOOD ( 17.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10.07.23 04:20, Anshuman Khandual wrote: > > > On 7/7/23 17:41, David Hildenbrand wrote: >> On 07.07.23 07:33, Anshuman Khandual wrote: >>> These pte_dirty() changes make things explicitly clear, while improving the >>> code readability. This optimizes HW dirty state transfer into SW dirty bit. >>> This also adds a new arm64 documentation explaining overall pte dirty state >>> management in detail. This series applies on the latest mainline kernel. >>> >>> >> >> I skimmed over most of the series, and I am not convinced that this is actually a cleanup. If we cannot really always differentiate between sw/hw clearing, why have separate primitives that give one the illusion that it could be done and that they are two different concepts? > > These are indeed two different concepts working together, the current code just > obscures that. Without these primitives it's even hard to follow how the SW and > HW dirty parts are intertwined in implementing the generic pte_dirty() state. > > The current code acknowledges these two different concepts in identifying them > i.e via pte_hw_dirty() and pte_sw_dirty(). > > #define pte_hw_dirty(pte) (pte_write(pte) && !(pte_val(pte) & PTE_RDONLY)) > #define pte_sw_dirty(pte) (!!(pte_val(pte) & PTE_DIRTY)) > ^ these primitives make sense to me, but not the clearing part. If there is only one way to clear both, then only have one primitive to clear both and state there, that separate clearing is impossible because both are intertwined. -- Cheers, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel