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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05810C433F5 for ; Mon, 8 Nov 2021 21:47:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D585461058 for ; Mon, 8 Nov 2021 21:47:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240604AbhKHVuR (ORCPT ); Mon, 8 Nov 2021 16:50:17 -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-Google-Smtp-Source: ABdhPJwEhyhfbeC/MNHqCWtg/FR+dr4b6RB3Mk6EDI6kjGv1xiTbmOpK8qZ+COSs0BLK3/7bdPcIQQ== 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.