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 10A6BC05027 for ; Sun, 12 Feb 2023 17:10:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229695AbjBLRKD (ORCPT ); Sun, 12 Feb 2023 12:10:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229556AbjBLRKB (ORCPT ); Sun, 12 Feb 2023 12:10:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7077F10A8C for ; Sun, 12 Feb 2023 09:10:00 -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 dfw.source.kernel.org (Postfix) with ESMTPS id EF3B060D3E for ; Sun, 12 Feb 2023 17:09:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50523C433D2; Sun, 12 Feb 2023 17:09:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676221799; bh=kLMQ5Pase67xP8drG8k+YSWnf+T+E+hyH8Jzj/ZHq6Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=idhp7qH5z5FlZhOPQeg6GKq1JXq+A+R7bBwD3AbEExMhL+pvkIBbmV80Xd+R8S5OM Tm2WevhCIdPzoxi6eMS+mWPAuVBZOsP9JqM04vkQVpLR3njtNxA02AgqumhEQVCcUg nnB5DYX4NEXGt3eVTNn/Cx1g8UF7IQKS9cGxCm2NC0PLt/umsuwiOpHG6BLyFatDFo KIWNiXLeMz0u7Vvkb0O8UfXgLjvI7cQrrJfeeRVkfZlf9ygSSbleshS47YYsavxzoK c0576AYJiupBuE86M4wrfFSv/jke6rjtxlmIkV2bag1zs16td3kNxFBcOyhTl/P/1E I6YuWA56eBGcw== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1pRFrR-009lH7-0k; Sun, 12 Feb 2023 17:09:57 +0000 Date: Sun, 12 Feb 2023 17:09:55 +0000 Message-ID: <87k00mlsik.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: <200246c2-9690-dabe-279e-13bc9beb711f@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> <8b67df9f-7d9e-23f7-f437-5aedbcfa985d@nutanix.com> <200246c2-9690-dabe-279e-13bc9beb711f@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/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: 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 Sat, 11 Feb 2023 06:52:02 +0000, Shivam Kumar wrote: > > > > > Hi Marc, > > > > I'm proposing this new implementation to address the concern you > > raised regarding dirty quota being a non-generic feature with the > > previous implementation. This implementation decouples dirty quota > > from dirty logging for the ARM64 arch. We shall post a similar > > implementation for x86 if this looks good. With this new > > implementation, dirty quota can be enforced independent of dirty > > logging. Dirty quota is now in bytes and > > Hi Marc, > > Thank you for your valuable feedback so far. Looking forward to your > feedback on this new proposition. I'm not sure what you are expecting from me here. I've explained in great details what I wanted to see, repeatedly. This above says nothing other than "we are going to do *something* that matches your expectations". My answer is, to quote someone else, "show me the code". Until then, I don't have much to add. Thanks, M. -- Without deviation from the norm, progress is not possible.