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 651A2C3DA78 for ; Sun, 15 Jan 2023 19:14:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231570AbjAOTOA (ORCPT ); Sun, 15 Jan 2023 14:14:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbjAOTN5 (ORCPT ); Sun, 15 Jan 2023 14:13:57 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFF5959D5 for ; Sun, 15 Jan 2023 11:13:56 -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 6AD76B80B32 for ; Sun, 15 Jan 2023 19:13:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E24E3C433D2; Sun, 15 Jan 2023 19:13:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673810033; bh=kRcIZyj6xxmCapygY9fw7DE+toWiK0NiIRek6NllMOY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RjiHYwnF4T5s+myyNs0x3sAap2mv6KE7VOYy2skfIRjrjsa8fl3XdfL1AsFMc8S1G LiA/3YlWel+js1VpsN1ooYKWeoxzOEQ2mLy6FFNO19D2lJG7ahxUUw/UMXHe0J8BC4 zt6/BJ/giXd/ZAGEiJNdiffNiu24yULJUJ/hGhQteyZAkTDuCkdEXheNRA8wV1XQHr afiYW8xiI49vB4eE9ee5tLunxOpFXVilPsIMqE+UHK0NW22evg0WG4NmvQK2o5LE2B j5NYwr1jJMCzthMGm/GOK99mXdu0idk5uXQOkevwLx9E578p4qm5r4zOrLO9Lwi+Lm nVT7RBIUVT8og== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pH8Rz-001xHk-Bn; Sun, 15 Jan 2023 19:13:51 +0000 Date: Sun, 15 Jan 2023 19:13:51 +0000 Message-ID: <865yd7obkg.wl-maz@kernel.org> From: Marc Zyngier To: Shivam Kumar Cc: Sean Christopherson , pbonzini@redhat.com, james.morse@arm.com, borntraeger@linux.ibm.com, david@redhat.com, kvm@vger.kernel.org, Shaju Abraham , Manish Mishra , Anurag Madnawat Subject: Re: [PATCH v7 1/4] KVM: Implement dirty quota-based throttling of vcpus In-Reply-To: <6cb4eb85-bfaa-10cd-5625-94605a5565f5@nutanix.com> References: <20221113170507.208810-1-shivam.kumar1@nutanix.com> <20221113170507.208810-2-shivam.kumar1@nutanix.com> <86zgcpo00m.wl-maz@kernel.org> <18b66b42-0bb4-4b32-e92c-3dce61d8e6a4@nutanix.com> <86mt8iopb7.wl-maz@kernel.org> <86ilinqi3l.wl-maz@kernel.org> <874jtifpg0.wl-maz@kernel.org> <77408d91-655a-6f51-5a3e-258e8ff7c358@nutanix.com> <87r0w6dnor.wl-maz@kernel.org> <4df8b276-595f-1ad7-4ce5-62435ea93032@nutanix.com> <87h6wsdstn.wl-maz@kernel.org> <6cb4eb85-bfaa-10cd-5625-94605a5565f5@nutanix.com> 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/28.2 (aarch64-unknown-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: shivam.kumar1@nutanix.com, seanjc@google.com, pbonzini@redhat.com, james.morse@arm.com, borntraeger@linux.ibm.com, david@redhat.com, kvm@vger.kernel.org, shaju.abraham@nutanix.com, manish.mishra@nutanix.com, anurag.madnawat@nutanix.com 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 Sun, 15 Jan 2023 14:50:55 +0000, Shivam Kumar wrote: > > >> Thank you Marc for the suggestion. We can make dirty quota count > >> dirtied memory rather than faults. > >> > >> run->dirty_quota -= page_size; > >> > >> We can raise a kvm request for exiting to userspace as soon as the > >> dirty quota of the vcpu becomes zero or negative. Please let me know > >> if this looks good to you. > > > > It really depends what "page_size" represents here. If you mean > > "mapping size", then yes. If you really mean "page size", then no. > > > > Assuming this is indeed "mapping size", then it all depends on how > > this is integrated and how this is managed in a generic, cross > > architecture way. > > > > Thanks, > > > > M. > > > > Yes, it is "mapping size". I can see that there's a "npages" variable > in "kvm_memory_slot" which determines the number of bits we need to > track dirtying for a given memory slot. And this variable is computed > by right shifting the memory size by PAGE_SHIFT. Each arch defines the > macro PAGE_SHIFT, and another macro PAGE_SIZE as the left shift of 1 > by PAGE_SHIFT. Does it make sense to use this macro? I don't think it makes any sense. There is nothing in the memslot structure that you can make use of. The information you need is the page table structure itself (the level, precisely), which tells you how big the mapping is for this particular part of the memslot. This is dynamic information, not defined at memslot creation. Which is why it can only be captured at fault time (with the exception of HugeTLBFS backed memslots for which the mapping size is cast into stone). M. -- Without deviation from the norm, progress is not possible.