Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2956469imm; Mon, 13 Aug 2018 03:35:15 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzeVXoqYVYJfhaOtoK8CHl6yCu+Q1Un3lulO/NsZV7IEQCU/qlMk1Hz9tb6ObdNlUHcfcOF X-Received: by 2002:a17:902:3204:: with SMTP id y4-v6mr16139013plb.195.1534156515673; Mon, 13 Aug 2018 03:35:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534156515; cv=none; d=google.com; s=arc-20160816; b=hFW/x3Eycrk91Hw2yn2Q9pK3XIfrShcydwwZ8ARRCvv5AtFcm5xuKwhKsO4vSXRKzv HYfhFbpCFyl5kEdgFIn0PfbEUeqS+M6KGDVYBD5xgPsamEcvhA8uyw8cBrchc1LUh0vM sxIru4vATOwVxeJ1lErPMvFuxvCjnBO5BgjYUPmOjbH8o/Qb2kYe+GxxG6o+p+Hsznsl UUKwo30QyNU61iXO6i/Dhp5+dlN8OxbfjmicEFOkuECYqfstlSQZ2M5z7Nd3vdWnczW8 7j4ymXpUfsSfiPLXlhaBePdt9IWUM9EabmtEj8JEtqqvYcC43l2vL3agQelNmU6Jc6lN coiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=lqu5SvzdjqMZRGtFWneB+B00z1+OKDC5W+YF/fx31Wo=; b=OHynCWWkQrzZ2f6XXvuRSnXB6K1/1BwHhpxoUQOEH5pr2HcM+/aNXXVHc+VekPeXyk 88ctGu4ose2jGxLzKQLWGHojeXFXiF5BMvNqA6UYH8TWSfC4ZpidRe3MNUJnUyFO26c5 ADlotTMT73MveZNK/SM9fE+fCMECx5OROw6CFUS7sB28nw1zyDMRPKnWJd87aCcLW43V zQurEoxE0f+mWiUO4IlCpD7Ty80BUvBbo7ytC10yadon0/JTKv8I6lM2XsrjEB8SGayJ r8Y4PRt7MdU3SoFk6Jf+39FgaEX7eLmBW2PVs1566i/JVseYQErgPiZq2TRNohGFR84N RaJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m76-v6si18194967pfg.323.2018.08.13.03.35.00; Mon, 13 Aug 2018 03:35:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728673AbeHMNAO (ORCPT + 99 others); Mon, 13 Aug 2018 09:00:14 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56542 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728055AbeHMNAO (ORCPT ); Mon, 13 Aug 2018 09:00:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C7F7F7A9; Mon, 13 Aug 2018 03:18:37 -0700 (PDT) Received: from localhost (e105922-lin.emea.arm.com [10.4.13.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6CBB83F5D0; Mon, 13 Aug 2018 03:18:37 -0700 (PDT) From: Punit Agrawal To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, stable@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/2] KVM: arm/arm64: Skip updating PMD entry if no change References: <20180813094049.3726-1-punit.agrawal@arm.com> <20180813094049.3726-2-punit.agrawal@arm.com> Date: Mon, 13 Aug 2018 11:18:35 +0100 In-Reply-To: (Marc Zyngier's message of "Mon, 13 Aug 2018 11:11:30 +0100") Message-ID: <87sh3i1sec.fsf@e105922-lin.cambridge.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marc Zyngier writes: > Hi Punit, > > On 13/08/18 10:40, Punit Agrawal wrote: [...] >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c >> index 1d90d79706bd..2ab977edc63c 100644 >> --- a/virt/kvm/arm/mmu.c >> +++ b/virt/kvm/arm/mmu.c >> @@ -1015,19 +1015,36 @@ static int stage2_set_pmd_huge(struct kvm *kvm, struct kvm_mmu_memory_cache >> pmd = stage2_get_pmd(kvm, cache, addr); >> VM_BUG_ON(!pmd); >> >> - /* >> - * Mapping in huge pages should only happen through a fault. If a >> - * page is merged into a transparent huge page, the individual >> - * subpages of that huge page should be unmapped through MMU >> - * notifiers before we get here. >> - * >> - * Merging of CompoundPages is not supported; they should become >> - * splitting first, unmapped, merged, and mapped back in on-demand. >> - */ >> - VM_BUG_ON(pmd_present(*pmd) && pmd_pfn(*pmd) != pmd_pfn(*new_pmd)); >> - >> old_pmd = *pmd; >> + >> if (pmd_present(old_pmd)) { >> + /* >> + * Mapping in huge pages should only happen through a >> + * fault. If a page is merged into a transparent huge >> + * page, the individual subpages of that huge page >> + * should be unmapped through MMU notifiers before we >> + * get here. >> + * >> + * Merging of CompoundPages is not supported; they >> + * should become splitting first, unmapped, merged, >> + * and mapped back in on-demand. >> + */ >> + VM_BUG_ON(pmd_pfn(old_pmd) != pmd_pfn(*new_pmd)); >> + >> + /* >> + * Multiple vcpus faulting on the same PMD entry, can >> + * lead to them sequentially updating the PMD with the >> + * same value. Following the break-before-make >> + * (pmd_clear() followed by tlb_flush()) process can >> + * hinder forward progress due to refaults generated >> + * on missing translations. >> + * >> + * Skip updating the page table if the entry is >> + * unchanged. >> + */ >> + if (pmd_val(old_pmd) == pmd_val(*new_pmd)) >> + goto out; > > I think the order of these two checks should be reversed: the first one > is clearly a subset of the second one, so it'd make sense to have the > global comparison before having the more specific one. Not that it > matter much in practice, but I just find it easier to reason about. Makes sense. I've reordered the checks for the next version. Thanks, Punit > >> + >> pmd_clear(pmd); >> kvm_tlb_flush_vmid_ipa(kvm, addr); >> } else { >> @@ -1035,6 +1052,7 @@ static int stage2_set_pmd_huge(struct kvm *kvm, struct kvm_mmu_memory_cache >> } >> >> kvm_set_pmd(pmd, *new_pmd); >> +out: >> return 0; >> } >> >> > > Thanks, > > M.