Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp689984pxb; Mon, 8 Nov 2021 21:27:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHqPYNqYXLMWTSTrNXoWoXDuZMw0WB8Ahj4/H45UuMvdQpGWByBsuxqeYaYPXglwHYuqX3 X-Received: by 2002:a05:6602:1645:: with SMTP id y5mr3098717iow.35.1636435660159; Mon, 08 Nov 2021 21:27:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636435660; cv=none; d=google.com; s=arc-20160816; b=WbCY5DBjm5UxpIL3Qht0wstxPNvEHmEWNc8FsPVOwSXKqxVUjSbEUn4m0+L+E+cUu3 3nN2+C4tipqckQx+AWgeK2PrIuOExYG8D5VMZzSpijCbGjnfxPiy6iBtFVxXcv6ccP3k +FxO4fXhVUjDXmKaE/EQsXbA2H3FARQrIiLktGyT8D+lMzf771G9B44Yr9dUSBkpyXrA LxLs4d5Z2nR4vSUoSBHYVZm7/GqDlSUCXQu4XI26vBOOIh+Xcws8DCTnvpScJllrSod6 x4Q6/9j6O5x9hmkvyTxQtjV3fsXlBuaMIyfGAh/2XRkzhd7DWZIgi5LIauiJFRswFyse BfxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8OQO6oRB/v20IjJtN8MTHcPwmaehnBhTjwZgesS0aJY=; b=hbmPu8PjW82xDZtOLjfxq37E/WH1c6pY13dP8FS0O01s1wD9fmFhZpCy7hQGRvJBRb c9mJyMyujG2jA7y2pWXQjj9byMayDsiLqO+GeR07tJDfCKHsMHpcS4e0LpItGOZT80RL MAdoVWXNItEZD90lbIkz9zFdxTKR63Lpn5WQd/twoCMqbvk08CbO9iK9iKqQ1CEuf6fp enUKoUxNr6wPfHm3pjd+YE0xWzUH9tuwRQXQWQFjmAuwC24C2v47oWTpbF7Ec3FNwQOA 3TVm0v36xrLZXwbFflWcv4gGE2gLfPf8yD4RZ+oMBXocjggglfPy2ZiySonbqHq8GWhR ShKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="q6+qt/2B"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f14si2794902ila.81.2021.11.08.21.27.26; Mon, 08 Nov 2021 21:27:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="q6+qt/2B"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240592AbhKHVuM (ORCPT + 99 others); Mon, 8 Nov 2021 16:50:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240591AbhKHVuG (ORCPT ); Mon, 8 Nov 2021 16:50:06 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E7B9C061746 for ; Mon, 8 Nov 2021 13:47:21 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id y1so17012512plk.10 for ; Mon, 08 Nov 2021 13:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8OQO6oRB/v20IjJtN8MTHcPwmaehnBhTjwZgesS0aJY=; b=q6+qt/2BIu8EOetYFoVHhDEyDdQV5s5qCX6YiuC30r8DgJ6jp0cGVWpCVSBDp6FVrN DPmmsshVYG2M97Zge1+5CAEVDRevaII7/Izdyz8QFCNob9ujrGau4qaAs9t7SVQWE6Dd bRWa1JQStU62M690RZ+Mrb48gqKAXaortZWbW4WHA9E7Y+uTs6Pf48VPmF+Dl2b0KOnB ZhwzS2Me591HXVrEL9HZeC17vGRR3nzggzOkwEGrLq3csDMyLp3YHCJn+69Ius93F53W pUtkyRRgyXzyCBTq4XOG9xHxfsgpSr7ojcFl6T7Du133m5DwDGxuY+pkiurd8fwZaaX+ pxHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8OQO6oRB/v20IjJtN8MTHcPwmaehnBhTjwZgesS0aJY=; b=x0p9OJ0Kukda71dCxbLxjXDYan0+eCian7tEonIB5lK1O3lod7hJs6Vn1yK8NAgz/M arlMUWNv1mRmlanxISRtJY7TaVgggapRtXE/sRVCVGOpXzlHRln7MDqdtOM2w24GwAQ7 ywxxLRhanGhbUd4GGb15vJudrRo3VI2H30vx8vqdFJUZF3FOC3pWhZ+dl6V3Rs20+ezG +m4QubgE9t7oAlkXzaEOKrxDYaYqqQtWQBPkONWw9TZrWSKeyIC8hDfPPWoY71aqPwec cA89ZX3wiKiEOMbBlIWJz8xQDuSNTc4fMfr3kfAOa+akxZr8+44ymixk1Lhoa8F6VsJV gqDA== X-Gm-Message-State: AOAM530IMh18R7HZLh6Dh4FlI2jOdVfxxsLfnN9T5fWSUGpnDETFKVl9 3JHnHRqSPCZnhDS05bWJ0Z8ezA== X-Received: by 2002:a17:90a:9295:: with SMTP id n21mr1568891pjo.229.1636408040857; Mon, 08 Nov 2021 13:47:20 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id u13sm13170875pga.92.2021.11.08.13.47.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Nov 2021 13:47:20 -0800 (PST) Date: Mon, 8 Nov 2021 21:47:16 +0000 From: Sean Christopherson To: Sergey Senozhatsky Cc: Paolo Bonzini , David Matlack , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Suleiman Souhlal , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHV2 3/3] KVM: x86: add KVM_SET_MMU_PREFETCH ioctl Message-ID: References: <20211019153214.109519-1-senozhatsky@chromium.org> <20211019153214.109519-4-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 20, 2021, Sergey Senozhatsky wrote: > On (21/10/20 00:32), Sergey Senozhatsky wrote: > > static int kvm_vm_ioctl_get_clock(struct kvm *kvm, void __user *argp) > > { > > struct kvm_clock_data data; > > @@ -6169,6 +6189,15 @@ long kvm_arch_vm_ioctl(struct file *filp, > > case KVM_X86_SET_MSR_FILTER: > > r = kvm_vm_ioctl_set_msr_filter(kvm, argp); > > break; > > + case KVM_SET_MMU_PREFETCH: { > > + u64 val; > > + > > + r = -EFAULT; > > + if (copy_from_user(&val, argp, sizeof(val))) > > + goto out; > > + r = kvm_arch_mmu_pte_prefetch(kvm, val); > > + break; > > + } > > A side question: is there any value in turning this into a per-VCPU ioctl? > So that, say, on heterogeneous systems big cores can prefetch more than > little cores, for instance. I don't think so? If anything, such behavior should probably be tied to the pCPU, not vCPU. Though I'm guessing the difference in optimal prefetch size between big and little cores is in the noise. I suspect the optimal prefetch size is more dependent on the guest workload than the core its running on. There's likely a correlation between the core size and the workload, but for that to have any meaning the vCPU would have be affined to a core (or set of cores), i.e having the behavior tied to the pCPU as opposed to the vCPU would work just as well. If the optimal setting is based on the speed of the core, not the workload, then per-pCPU is again preferable as it "works" regardless of vCPU affinity.