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 B3B49EB64DC for ; Mon, 10 Jul 2023 02:21:12 +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-Transfer-Encoding:Content-Type: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=a4dLAcOe+gkTYxPKQ9UttC8zE+YYz7QdJdWrbkdU11o=; b=Sf2/93XnMwSQhR 43muZby75Js9Rr+Q92OUNX1/F1Q0tQgkxEj+6FN93BTtvLO5jztv3JATioEqtZqVHsCcIyAQpmYjK MZ1c4ng5ZzQK5kSjNFloxQhuMGqaTh6Qs0zMzt10fh4iGgcq2KnyAy8SkfluMbKkCWE2aGmEsbBH5 Tbj2qcGneCIpUqQRy7e0e5KUPVcqv36kSEfcm2yV/43toJm7rK+l1KhREEp8ILHsVJBvExg9ZsvzY vw+Vj2Qq954Jv70pOKKPx/hPb1OhWvuYdT6UWc83vxuqzTH5zfp5Pw6bq+B90CsZcUqyv2ztoraOP dZgSiCScJMoLnbLH5JbQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qIgW6-00ABAH-3B; Mon, 10 Jul 2023 02:20:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qIgW3-00AB95-26 for linux-arm-kernel@lists.infradead.org; Mon, 10 Jul 2023 02:20:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 304891FB; Sun, 9 Jul 2023 19:21:19 -0700 (PDT) Received: from [10.162.40.20] (a077893.blr.arm.com [10.162.40.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E335A3F740; Sun, 9 Jul 2023 19:20:33 -0700 (PDT) Message-ID: <60732ee3-f1c5-3534-29fc-783ec48f2c92@arm.com> Date: Mon, 10 Jul 2023 07:50:30 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [RFC 0/4] arm64/mm: Clean up pte_dirty() state management To: David Hildenbrand , 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> Content-Language: en-US From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230709_192043_758799_F18B747B X-CRM114-Status: GOOD ( 16.66 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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)) But then falls short in demonstrating how these two states are being managed i.e created and cleared. The first patch tries to clear the situation to some extent. > > Maybe there are other opinions, but at least for me this made the code harder to grasp. > > I do appreciate a doc update, though :) These two changes also streamline HW dirty bit saving in SW dirty bit efficiently, skipping the re-doing of HW dirty bits setting which might be cleared off. That is the primary reason for saving it off in SW dirty bit in the first place. arm64/mm: Call pte_sw_mkdirty() while preserving the HW dirty state arm64/mm: Add pte_preserve_hw_dirty( Regardless, I am still trying to understand how the first patch does not improve the clarity in modifying the PTE dirty state. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel