From patchwork Thu Jan 31 18:37:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerome Glisse X-Patchwork-Id: 10791179 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0C987139A for ; Thu, 31 Jan 2019 18:37:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 05E15310F5 for ; Thu, 31 Jan 2019 18:37:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id ED90431111; Thu, 31 Jan 2019 18:37:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8C792310F5 for ; Thu, 31 Jan 2019 18:37:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726823AbfAaShQ (ORCPT ); Thu, 31 Jan 2019 13:37:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55440 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725777AbfAaShQ (ORCPT ); Thu, 31 Jan 2019 13:37:16 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8EEC4CCB60; Thu, 31 Jan 2019 18:37:15 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.20.6.236]) by smtp.corp.redhat.com (Postfix) with ESMTP id BBCCD19492; Thu, 31 Jan 2019 18:37:13 +0000 (UTC) From: jglisse@redhat.com To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Andrea Arcangeli , Peter Xu , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andrew Morton , Matthew Wilcox , Paolo Bonzini , =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= , Michal Hocko , kvm@vger.kernel.org Subject: [RFC PATCH 0/4] Restore change_pte optimization to its former glory Date: Thu, 31 Jan 2019 13:37:02 -0500 Message-Id: <20190131183706.20980-1-jglisse@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 31 Jan 2019 18:37:15 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jérôme Glisse This patchset is on top of my patchset to add context information to mmu notifier [1] you can find a branch with everything [2]. I have not tested it but i wanted to get the discussion started. I believe it is correct but i am not sure what kind of kvm test i can run to exercise this. The idea is that since kvm will invalidate the secondary MMUs within invalidate_range callback then the change_pte() optimization is lost. With this patchset everytime core mm is using set_pte_at_notify() and thus change_pte() get calls then we can ignore the invalidate_range callback altogether and only rely on change_pte callback. Note that this is only valid when either going from a read and write pte to a read only pte with same pfn, or from a read only pte to a read and write pte with different pfn. The other side of the story is that the primary mmu pte is clear with ptep_clear_flush_notify before the call to change_pte. Also with the mmu notifier context information [1] you can further optimize other cases like mprotect or write protect when forking. You can use the new context information to infer that the invalidation is for read only update of the primary mmu and update the secondary mmu accordingly instead of clearing it and forcing fault even for read access. I do not know if that is an optimization that would bear any fruit for kvm. It does help for device driver. You can also optimize the soft dirty update. Cheers, Jérôme [1] https://lore.kernel.org/linux-fsdevel/20190123222315.1122-1-jglisse@redhat.com/T/#m69e8f589240e18acbf196a1c8aa1d6fc97bd3565 [2] https://cgit.freedesktop.org/~glisse/linux/log/?h=kvm-restore-change_pte Cc: Andrea Arcangeli Cc: Peter Xu Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Andrew Morton Cc: Matthew Wilcox Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Michal Hocko Cc: kvm@vger.kernel.org Jérôme Glisse (4): uprobes: use set_pte_at() not set_pte_at_notify() mm/mmu_notifier: use unsigned for event field in range struct mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate kvm/mmu_notifier: re-enable the change_pte() optimization. include/linux/mmu_notifier.h | 21 +++++++++++++++++++-- kernel/events/uprobes.c | 3 +-- mm/ksm.c | 6 ++++-- mm/memory.c | 3 ++- virt/kvm/kvm_main.c | 16 ++++++++++++++++ 5 files changed, 42 insertions(+), 7 deletions(-)