Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230608220558.39094-1-ctshao@google.com> <20230608220558.39094-4-ctshao@google.com>
 <878rctnkqg.wl-maz@kernel.org>
In-Reply-To: <878rctnkqg.wl-maz@kernel.org>
From:   Chun-Tse Shao <ctshao@google.com>
Date:   Fri, 9 Jun 2023 15:58:44 -0700
Message-ID: <CAJpZYjVcDAU94Abx7BUV-nZeTJ88ggYs=n8gBUyRUGQ=iQWPvw@mail.gmail.com>
Subject: Re: [PATCH v1 3/3] KVM: arm64: Using rcu_read_lock() for kvm_pgtable_stage2_mkyoung()
To:     Marc Zyngier <maz@kernel.org>
Cc:     linux-kernel@vger.kernel.org, yuzhao@google.com,
        oliver.upton@linux.dev, James Morse <james.morse@arm.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Zenghui Yu <yuzenghui@huawei.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Ben Gardon <bgardon@google.com>,
        Gavin Shan <gshan@redhat.com>,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jun 9, 2023 at 12:44=E2=80=AFAM Marc Zyngier <maz@kernel.org> wrote=
:
>
> On Thu, 08 Jun 2023 23:05:41 +0100,
> Chun-Tse Shao <ctshao@google.com> wrote:
> >
> > Access bit is RCU safe and can be set without taking kvm->mmu_lock().
>
> Please explain why. What happens when the page tables are *not* RCU
> controlled, such as in the pKVM case?
>
> > Replacing existing kvm->mmu_lock() with rcu_read_lock() for better
> > performance.
>
> Please define "better performance", quote workloads, figures, HW setup
> and point to a reproducer. Please add a cover letter to your patch
> series explaining the context this happens in.

Thanks for the suggestion, we are currently working on the performance
test in parallel and will update after gathering more data.

>
> Also, I'm getting increasingly annoyed by the lack of coordination
> between seamingly overlapping patch series (this, Yu's, Anish's and
> Vipin's), all from a single company.
>
> Surely you can talk to each other and devise a coordinated approach?

Sure, I will start internal meeting as needed.

>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Thanks,
CT