From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9B012F2A for ; Thu, 23 Feb 2023 17:34:55 +0000 (UTC) Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-536bbaeceeaso138936017b3.11 for ; Thu, 23 Feb 2023 09:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=fvEBJKNTVgASaDjc9Q0VXXTAIHEeqbLAf/33eHK5qtIch5pppRvvtww/N2ViF2gpdq VCAiByWM0l/uNFtxN6iV9hK9EY1uZL/NFtqzu8+sHL4tj8XGIV3zT+VWHXk8cqOcs76m 313IP1Iu0V/gvoPT+akxf2tRfrtOogk7Aohae/b/Aowp4hWjO+AiMIwooblfNsZUhyiu U4MrCMNErtTs5EP+Mg3bg1pBjkaTPY96RUHhEDGrAVECxaGcvdLPa0vW0CY9T5AOps78 5vvq/sVqQVqjMo9ETUdGV8sO5IdO/RVjAtFU/I637xYFOPP6pd7vWPL3FWBwSWirJEqB rtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=XXjJlSZi49NKIsL+5/Ivqg7gOwjoSQJ8ijNoHSxn+A2NXKCUsZU0G785xyPDLoxzz4 nUZ6669xFfnld4ra+5NWJh6LDWk/ERMBfTbZ/Anfl1R9g4nYFpwH+G5V4WQOkGJTXfcF ztmR8RYA7Lz/ZHKcAXvD0xA8gOczqq88z6npRwWtATvfunU4dCx5eoiEIGoC3AQVE6sy BHeWvEs352pQZhRbq5b2LBCXLGmKY7rc4Dcg9OpZH0LniccVsMJEPeT2L9PcqOEKtd+6 NDfbB0rNjxOD3d6XKu9I2Q0hDv+vv1tGnrK/rkbB5h0FSyDBqCAv+c74Jz8f25o2FZua MXqA== X-Gm-Message-State: AO0yUKVL5gZ7OdWBkmX5F9xIluwFeTyhPOSbTHRS8fCtFSBJZqckpzxk tRvKXzlmBy4Sg9C/lygFIsT7MffkAkg= X-Google-Smtp-Source: AK7set9qM18OCmCtNF4MtwIz5dX/Eaw8z+NF94C05s0wfxF7vpTFz86wUpljUQl+IzVT57C5nxDYcFR2baU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:524e:0:b0:534:7482:b73 with SMTP id g75-20020a81524e000000b0053474820b73mr788300ywb.153.1677173694654; Thu, 23 Feb 2023 09:34:54 -0800 (PST) Date: Thu, 23 Feb 2023 09:34:52 -0800 In-Reply-To: <20230217041230.2417228-2-yuzhao@google.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-2-yuzhao@google.com> Message-ID: Subject: Re: [PATCH mm-unstable v1 1/5] mm/kvm: add mmu_notifier_test_clear_young() From: Sean Christopherson To: Yu Zhao Cc: Andrew Morton , Paolo Bonzini , Jonathan Corbet , Michael Larabel , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-mm@google.com Content-Type: text/plain; charset="us-ascii" On Thu, Feb 16, 2023, Yu Zhao wrote: > +static bool kvm_mmu_notifier_test_clear_young(struct mmu_notifier *mn, struct mm_struct *mm, > + unsigned long start, unsigned long end, > + unsigned long *bitmap) > +{ > + if (kvm_arch_has_test_clear_young()) > + return kvm_test_clear_young(mmu_notifier_to_kvm(mn), start, end, bitmap); > + > + return false; > +} > + > static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long address) > @@ -903,6 +960,7 @@ static const struct mmu_notifier_ops kvm_mmu_notifier_ops = { > .clear_flush_young = kvm_mmu_notifier_clear_flush_young, > .clear_young = kvm_mmu_notifier_clear_young, > .test_young = kvm_mmu_notifier_test_young, > + .test_clear_young = kvm_mmu_notifier_test_clear_young, I am strongly opposed to adding yet another "young" mmu_notifier hook for this. I would much rather we extend (and rename) mmu_notifier_clear_young() to take the bitmap as an optional parameter, and then have KVM hide the details of whether or not it supports lockless processing of the range/bitmap. I also think for KVM x86 in particular, this series should first convert to a lockless walk for aging ranges, and then add the batching. It might also make sense to land x86 first and then follow-up with ARM and PPC. I haven't looked at the ARM or PPC patches in too much depth, but on the x86 side of things KVM already has the pieces in place to support a fully lockless walk, i.e. the x86 specific changes aren't all that contentious, the only thing we need to figure out is what to do about nested VMs. 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 44BE7C636D6 for ; Thu, 23 Feb 2023 17:35:55 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PN0YP4v7Vz3chK for ; Fri, 24 Feb 2023 04:35:53 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=fvEBJKNT; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::114a; helo=mail-yw1-x114a.google.com; envelope-from=3vqp3ywykdas3plyunrzzrwp.nzxwty5800n-op6wt343.zawlm3.z2r@flex--seanjc.bounces.google.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=fvEBJKNT; dkim-atps=neutral Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4PN0XM5TJWz30hl for ; Fri, 24 Feb 2023 04:34:57 +1100 (AEDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-536a4eba107so155296797b3.19 for ; Thu, 23 Feb 2023 09:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=fvEBJKNTVgASaDjc9Q0VXXTAIHEeqbLAf/33eHK5qtIch5pppRvvtww/N2ViF2gpdq VCAiByWM0l/uNFtxN6iV9hK9EY1uZL/NFtqzu8+sHL4tj8XGIV3zT+VWHXk8cqOcs76m 313IP1Iu0V/gvoPT+akxf2tRfrtOogk7Aohae/b/Aowp4hWjO+AiMIwooblfNsZUhyiu U4MrCMNErtTs5EP+Mg3bg1pBjkaTPY96RUHhEDGrAVECxaGcvdLPa0vW0CY9T5AOps78 5vvq/sVqQVqjMo9ETUdGV8sO5IdO/RVjAtFU/I637xYFOPP6pd7vWPL3FWBwSWirJEqB rtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=r/1lMhnWKienQvYxv8dQ4bWfzS1RlJ0aogUjIKkp3z3G+QI6tCXIHo2OmrmkzKoyFn DcbQ27RhNkvFS2MfPQQ+UXc+tjxyZRV6W9AlDUSqgf4w9QxDYYXRRoNCnwXqf81gic/Y 5lJRuWsFqCjkekcJUnEzcxpBP/9KUA72gVBkkgEb1XRz01itj0QDqm/BzkuBpvWH3S0H WCBZs88qLv3cRjQFzDot15i7h4jEKtQ3oR5fKiRvUBCDuQFkywlAK3X/2zyOUrLois59 OJ5g6sHSbJQhpEoL7G7Vm6raWs1iolwAIWSZ7Fwm2m/t0ByMO4/axMDEDGPdBzK3GwDC /CLQ== X-Gm-Message-State: AO0yUKXh+TpiqERLj30+Nh9dkEjZuqqJPilQCQuKh2P1b40lXfCowGpT xt8HiyhjQ/Ldn52AVu0hMz7e8609URU= X-Google-Smtp-Source: AK7set9qM18OCmCtNF4MtwIz5dX/Eaw8z+NF94C05s0wfxF7vpTFz86wUpljUQl+IzVT57C5nxDYcFR2baU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:524e:0:b0:534:7482:b73 with SMTP id g75-20020a81524e000000b0053474820b73mr788300ywb.153.1677173694654; Thu, 23 Feb 2023 09:34:54 -0800 (PST) Date: Thu, 23 Feb 2023 09:34:52 -0800 In-Reply-To: <20230217041230.2417228-2-yuzhao@google.com> Mime-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-2-yuzhao@google.com> Message-ID: Subject: Re: [PATCH mm-unstable v1 1/5] mm/kvm: add mmu_notifier_test_clear_young() From: Sean Christopherson To: Yu Zhao Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mm@google.com, kvm@vger.kernel.org, Jonathan Corbet , Michael Larabel , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, Paolo Bonzini , Andrew Morton , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Feb 16, 2023, Yu Zhao wrote: > +static bool kvm_mmu_notifier_test_clear_young(struct mmu_notifier *mn, struct mm_struct *mm, > + unsigned long start, unsigned long end, > + unsigned long *bitmap) > +{ > + if (kvm_arch_has_test_clear_young()) > + return kvm_test_clear_young(mmu_notifier_to_kvm(mn), start, end, bitmap); > + > + return false; > +} > + > static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long address) > @@ -903,6 +960,7 @@ static const struct mmu_notifier_ops kvm_mmu_notifier_ops = { > .clear_flush_young = kvm_mmu_notifier_clear_flush_young, > .clear_young = kvm_mmu_notifier_clear_young, > .test_young = kvm_mmu_notifier_test_young, > + .test_clear_young = kvm_mmu_notifier_test_clear_young, I am strongly opposed to adding yet another "young" mmu_notifier hook for this. I would much rather we extend (and rename) mmu_notifier_clear_young() to take the bitmap as an optional parameter, and then have KVM hide the details of whether or not it supports lockless processing of the range/bitmap. I also think for KVM x86 in particular, this series should first convert to a lockless walk for aging ranges, and then add the batching. It might also make sense to land x86 first and then follow-up with ARM and PPC. I haven't looked at the ARM or PPC patches in too much depth, but on the x86 side of things KVM already has the pieces in place to support a fully lockless walk, i.e. the x86 specific changes aren't all that contentious, the only thing we need to figure out is what to do about nested VMs. 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 569FCC6379F for ; Thu, 23 Feb 2023 17:35:58 +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:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=WKT7a/S5nxu3DsrKkYkzZux1HLreBVC/sOO5N4OIpKs=; b=jnKJPJVnvhX3BILetIRS2aMaNe UamQXxuYmsDDqmQQavPggD2LNRCbJACu9GLQfgYVankrAv+hnoIWqHYyRvdGLFkR3VMaQccR6kmsK wBbKKkxQTWh2uaA7msrFh9u8Iyz5tv8oi7r7E4Q2+7BfM+cFjMSBkBPKd5LQLlqy7nEut43P+STex N2qyWMhhYX+jQffFzTyFb4u+e0yl9bqUjO65cIFB7Pq7ViF1xtMBtXSkEiu5uwTdJvdLX+dLvW+WM +Id3w+1J0g6U6kl+M3T4+jnjrFVk4tLd2XnLCOHbZAHvhXOIOWZ5awvRxXVsQtnPATGr11adEv0dQ 7QAubdLw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVFUj-00HNtf-Jj; Thu, 23 Feb 2023 17:35:01 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVFUg-00HNs2-PI for linux-arm-kernel@lists.infradead.org; Thu, 23 Feb 2023 17:35:00 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-536cad819c7so126439957b3.6 for ; Thu, 23 Feb 2023 09:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=fvEBJKNTVgASaDjc9Q0VXXTAIHEeqbLAf/33eHK5qtIch5pppRvvtww/N2ViF2gpdq VCAiByWM0l/uNFtxN6iV9hK9EY1uZL/NFtqzu8+sHL4tj8XGIV3zT+VWHXk8cqOcs76m 313IP1Iu0V/gvoPT+akxf2tRfrtOogk7Aohae/b/Aowp4hWjO+AiMIwooblfNsZUhyiu U4MrCMNErtTs5EP+Mg3bg1pBjkaTPY96RUHhEDGrAVECxaGcvdLPa0vW0CY9T5AOps78 5vvq/sVqQVqjMo9ETUdGV8sO5IdO/RVjAtFU/I637xYFOPP6pd7vWPL3FWBwSWirJEqB rtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4HvtD+IMg3vyDXGpZcS0GeFnM8gx7HgAcp0Q62lmtW4=; b=06Z1c2YkHhUl88t47aaBrn89u4XcpHo7oAAVVHRgGFhHyxqY4NMyxLGvUpqe/SaabM 9WVKrGVnclOPAbijvrMFsFKG568FenMZyufBcuVUwwhV04LUGzctTw4LPx0l93Tl0yJ+ alh9yffE4ltkBAUIg+Fg0tt4ZI4nDZQXAbRddkw9S5ca+YhZw9fDYwMdyGoe8ZGOQb+H ke+eqhrhxaDCbWk2SKVwLA73gdirylf0Fn5GOXI8AhA94LueepqXdjEJ4Q/uge21r5BM I+q0eIdh+dxJDyiWrmMfdt7eoT0aKhPGiT3cOc3rUzzUwhcVRE/UYwSR4q8Er6xs4sGZ TkwA== X-Gm-Message-State: AO0yUKUq9B4e+Dbk004BtlnY8j1vvAmtIiwW2t2TbJMkdNI6BtEWckuu cqREltrNdtH1053qB/lLDXVZ72120HE= X-Google-Smtp-Source: AK7set9qM18OCmCtNF4MtwIz5dX/Eaw8z+NF94C05s0wfxF7vpTFz86wUpljUQl+IzVT57C5nxDYcFR2baU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:524e:0:b0:534:7482:b73 with SMTP id g75-20020a81524e000000b0053474820b73mr788300ywb.153.1677173694654; Thu, 23 Feb 2023 09:34:54 -0800 (PST) Date: Thu, 23 Feb 2023 09:34:52 -0800 In-Reply-To: <20230217041230.2417228-2-yuzhao@google.com> Mime-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-2-yuzhao@google.com> Message-ID: Subject: Re: [PATCH mm-unstable v1 1/5] mm/kvm: add mmu_notifier_test_clear_young() From: Sean Christopherson To: Yu Zhao Cc: Andrew Morton , Paolo Bonzini , Jonathan Corbet , Michael Larabel , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-mm@google.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230223_093458_841590_9DC079AA X-CRM114-Status: GOOD ( 16.31 ) 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 Thu, Feb 16, 2023, Yu Zhao wrote: > +static bool kvm_mmu_notifier_test_clear_young(struct mmu_notifier *mn, struct mm_struct *mm, > + unsigned long start, unsigned long end, > + unsigned long *bitmap) > +{ > + if (kvm_arch_has_test_clear_young()) > + return kvm_test_clear_young(mmu_notifier_to_kvm(mn), start, end, bitmap); > + > + return false; > +} > + > static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long address) > @@ -903,6 +960,7 @@ static const struct mmu_notifier_ops kvm_mmu_notifier_ops = { > .clear_flush_young = kvm_mmu_notifier_clear_flush_young, > .clear_young = kvm_mmu_notifier_clear_young, > .test_young = kvm_mmu_notifier_test_young, > + .test_clear_young = kvm_mmu_notifier_test_clear_young, I am strongly opposed to adding yet another "young" mmu_notifier hook for this. I would much rather we extend (and rename) mmu_notifier_clear_young() to take the bitmap as an optional parameter, and then have KVM hide the details of whether or not it supports lockless processing of the range/bitmap. I also think for KVM x86 in particular, this series should first convert to a lockless walk for aging ranges, and then add the batching. It might also make sense to land x86 first and then follow-up with ARM and PPC. I haven't looked at the ARM or PPC patches in too much depth, but on the x86 side of things KVM already has the pieces in place to support a fully lockless walk, i.e. the x86 specific changes aren't all that contentious, the only thing we need to figure out is what to do about nested VMs. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel