From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBA725E07E for ; Thu, 4 Apr 2024 09:20:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712222401; cv=none; b=fcoQq2dKXS1EY31bVX4rxgjjjV6Tkn0e/f7jQs9P7WvObMZlDn7375EfkPFUorPNL2TW65HNcCwHg2Q3rXWG8pkxDXQ0H+NXhHq92pEayNSzfQYpZLbyM9UkaW/UesXCGFGltw+QvG2huG9i4YKDKmEdHCeZYE/F+SWBV8UM9yo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712222401; c=relaxed/simple; bh=2FVNMLmDPixAiJz9IV2WhhjVMeHUhCQJ24ayf9+a34o=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=JfZdihk7qbMCs91UXjF9U8yaHLm0JZB/ReGUWYZPx/o+Udp5tKeB1kF9U6yIJgtBMnPvBb1Ik2ccxEq3CDEK8n5kq/br9IiryoWqItnWVRex7+LKeyJaxqdwBOhvKi9JgB+Cr58Crynef8h0eWqFvPD6xwXuX54d7PN2fndQSKc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sUkBVkd2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sUkBVkd2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6379BC433F1; Thu, 4 Apr 2024 09:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712222401; bh=2FVNMLmDPixAiJz9IV2WhhjVMeHUhCQJ24ayf9+a34o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sUkBVkd2tn9BUwKrBTw9hu2FYigsr9H3Pb9b5gs7bqPfn9mclVVYcjmCDSvsHRZvU P469b92Hg31f3EFvlNdZe6wwRMecD6G+VdxX/LWygBCY40Mp5dts88ql3ecY2hDEYC cjbkq+mOBoPXSJDtbXBhj2P5+RNuKg5EPR5+3OPVy1v2oW92dkV7UnYNnvWkE6WkSj YFJ6PEO6OGAhRe2lk3RVC/hMBwc8gCo2QBYK92TdyYFwkzCYspmFZXyYwIMkkH/IqV CwtlGq0CrLrkaCi8kFaD4/fWGayXxB73wwdH+T32olMYrrp9kxMDhaICkXlLczHxfh V4GmDHZJ0iQ5Q== Received: from [185.201.63.251] (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 1rsJGI-001PxT-Sz; Thu, 04 Apr 2024 10:19:59 +0100 Date: Thu, 04 Apr 2024 10:19:50 +0100 Message-ID: <87h6ghscw9.wl-maz@kernel.org> From: Marc Zyngier To: Shivam Kumar Cc: "pbonzini@redhat.com" , "seanjc@google.com" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , "oliver.upton@linux.dev" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , Aravind Retnakaran , "Carl Waldspurger [C]" , David Vrabel , "david@redhat.com" , "will@kernel.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH v10 0/3] Per-vCPU dirty quota-based throttling In-Reply-To: References: <20240221195125.102479-1-shivam.kumar1@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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.201.63.251 X-SA-Exim-Rcpt-To: shivam.kumar1@nutanix.com, pbonzini@redhat.com, seanjc@google.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, catalin.marinas@arm.com, aravind.retnakaran@nutanix.com, carl.waldspurger@nutanix.com, david.vrabel@nutanix.com, david@redhat.com, will@kernel.org, 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 On Thu, 21 Mar 2024 05:48:01 +0000, Shivam Kumar wrote: >=20 >=20 > > On 22-Feb-2024, at 1:22 AM, Shivam Kumar wr= ote: > >=20 > > The current v10 patchset includes the following changes over v9: > >=20 > > 1. Use vma_pagesize as the dirty granularity for updating dirty quota > > on arm64. > > 2. Do not update dirty quota for instances where the hypervisor is > > writing into guest memory. Accounting for these instances in vCPUs' > > dirty quota is unfair to the vCPUs. Also, some of these instances, > > such as record_steal_time, frequently try to redundantly mark the same > > set of pages dirty again and again. To avoid these distortions, we had > > previously relied on checking the dirty bitmap to avoid redundantly > > updating quotas. Since we have now decoupled dirty-quota-based > > throttling from the live-migration dirty-tracking path, we have > > resolved this issue by simply avoiding the mis-accounting caused by > > these hypervisor-induced writes to guest memory. Through extensive > > experiments, we have verified that this new approach is approximately > > as effective as the prior approach that relied on checking the dirty > > bitmap. > >=20 >=20 > Hi Marc, >=20 > I=E2=80=99ve tried my best to address all the concerns raised in the > previous patchset. I=E2=80=99d really appreciate it if you could share yo= ur > thoughts and any feedback you might have on this one. I'll get to it at some point. However, given that it has you taken the best part of a year to respin this, I need to page it all back it, which is going to take a bit of time as well. Thanks, M. --=20 Without deviation from the norm, progress is not possible.