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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6969C433F5 for ; Thu, 10 Mar 2022 08:30:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240334AbiCJIbi (ORCPT ); Thu, 10 Mar 2022 03:31:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232250AbiCJIbh (ORCPT ); Thu, 10 Mar 2022 03:31:37 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 094C8135701 for ; Thu, 10 Mar 2022 00:30:35 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4E9D2B82549 for ; Thu, 10 Mar 2022 08:30:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10005C340E8; Thu, 10 Mar 2022 08:30:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646901033; bh=x2w4YCh8zXACrKp+r92F1M5/iu5aNSGm4udnt9xxu9Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B5WtLt39l2iASMRRDy7YhKUHMA2M1rMfc5M5QIU01BWemlZrfw4DGKKm20U64OUD1 tSf63zMrtYcMsTJprGHUMFc9U7IwOqLJKKxJpaqn1ZheluiovgBpuTaCp7h8El0D2n MIwm3vBN+0/YShFHn0f2NGoghAk0VagkSIn5T8pBhotb4p1skcuYffd9ZiW9jBn6Ew oONNl/OX0dQdu8B+TSyGB/WrV8OxfqK9xXsZh5gNribZKq5KBMp5SCCkOSo5H4SfPz +qfjjd7Kd7icdl4ie4sxbdGJsTB7e6mPAW24qt8la80eesNykdPBRX80shO87KQlgZ ghfm/bgKkioBA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nSEBq-00DWbd-JW; Thu, 10 Mar 2022 08:30:30 +0000 Date: Thu, 10 Mar 2022 08:30:30 +0000 Message-ID: <87r17ayztl.wl-maz@kernel.org> From: Marc Zyngier To: David Matlack Cc: Paolo Bonzini , Huacai Chen , leksandar Markovic , Sean Christopherson , Vitaly Kuznetsov , Peter Xu , Wanpeng Li , Jim Mattson , Joerg Roedel , Peter Feiner , Andrew Jones , "Maciej S. Szmigiero" , kvm list Subject: Re: [PATCH 19/23] KVM: Allow for different capacities in kvm_mmu_memory_cache structs In-Reply-To: References: <20220203010051.2813563-1-dmatlack@google.com> <20220203010051.2813563-20-dmatlack@google.com> <8735k84i6f.wl-maz@kernel.org> <878rtotk3h.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dmatlack@google.com, pbonzini@redhat.com, chenhuacai@kernel.org, aleksandar.qemu.devel@gmail.com, seanjc@google.com, vkuznets@redhat.com, peterx@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, pfeiner@google.com, drjones@redhat.com, maciej.szmigiero@oracle.com, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 09 Mar 2022 21:49:01 +0000, David Matlack wrote: > > On Mon, Mar 7, 2022 at 3:49 PM David Matlack wrote: > > > > On Sat, Mar 5, 2022 at 8:55 AM Marc Zyngier wrote: > > > > > > On Fri, 04 Mar 2022 21:59:12 +0000, > > > David Matlack wrote: > > > > I see two alternatives to make this cleaner: > > > > > > > > 1. Dynamically allocate just this cache. The caches defined in > > > > vcpu_arch will continue to use DEFINE_KVM_MMU_MEMORY_CACHE(). This > > > > would get rid of the outer struct but require an extra memory > > > > allocation. > > > > 2. Move this cache to struct kvm_arch using > > > > DEFINE_KVM_MMU_MEMORY_CACHE(). Then we don't need to stack allocate it > > > > or dynamically allocate it. > > > > > > > > Do either of these approaches appeal to you more than the current one? > > > > > > Certainly, #2 feels more solid. Dynamic allocations (and the resulting > > > pointer chasing) are usually costly in terms of performance, so I'd > > > avoid it if at all possible. > > > > > > That being said, if it turns out that #2 isn't practical, I won't get > > > in the way of your current approach. Moving kvm_mmu_memory_cache to > > > core code was definitely a good cleanup, and I'm not overly excited > > > with the perspective of *more* arch-specific code. > > > > Ok I'll play with #2. Thanks for the feedback. > > #2 is very clean to implement but it ends up being a bit silly. It > increases the size of struct kvm_arch by 336 bytes for all VMs but > only ever gets used during kvm_vgic_map_resources(), which is only > called the first time a vCPU is run (according to the comment in > kvm_arch_vcpu_run_pid_change()). I think stack allocation makes the > most sense for this object, I don't think it's worth dancing around > that solely to avoid the inner struct grottiness. Fair enough, and thanks for having had a look. I'll look at the next version once you post it. Thanks, M. -- Without deviation from the norm, progress is not possible.