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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4CD37CA9ED1 for ; Mon, 12 Oct 2026 11:31:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UKbDbkFJt72t2zaBIh+ZUe3E29MXtHewW5fvZXZCj30=; b=YzAGJy0AKXvq0WsihWJQtdc6Cq f68ZYusGNY5fPUjoZlaQxTrhMjjVJvHN5i436aRJ2G9qV6ndPWUg0KZgQdMEOE8vvNQuzixbykrpe n2tCpHfNrFvvuWxeZYvv8NcNfiLxtbek2XT+EObCiDwjD9KvQLG16LGYH9dRRFzAtC7xNFNPpTTq6 ETrhAXhCqBHFXEJkzwZyAhzX6pxmtLfQuv4/hgNX5yi/sHFHT1e6FGYgq5RKPeM1ftCXi3527tX1/ bXX2z0dRnJw7w3JPZGPvLIMOkaCXDhYQsPZgeD54iDim89J9PC69EygKvffNVeBYtJTNY0Wv5dqnB J8SpjmmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xGEFW-0000000AM8r-3x0P; Mon, 12 Oct 2026 11:31:22 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xGEFV-0000000AM8E-3LIg for linux-arm-kernel@lists.infradead.org; Mon, 12 Oct 2026 11:31:21 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id EB79560229; Mon, 12 Oct 2026 11:31:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0D681F0089B; Mon, 12 Oct 2026 11:31:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791804680; bh=UKbDbkFJt72t2zaBIh+ZUe3E29MXtHewW5fvZXZCj30=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GG0crorOYWxX9858zOkG7h2+X99LFStJ4Gi8/a5Drk5bO6EswnhtjYKFxLtZt8h4v FqWT41IP8Ehk2C/+UT4t68wZgWCbVd9ccW7oEqHevvJi6EfSWQxTa1AjZMgk6k3j8u ugOmsxlfttwzXePsildhyn3jj5iL3LG673ZL4PpuDTVHcsQh4g5PfnjnTRhKZbh6x+ BYJ7LRg0UFaH6olen9aZ42c6+9FhgGQ1mO1hAOAoe2BsAI9MuZ3RqAQ8Q0x8ccp0wC 5vea+Oyry6rwXwBdEIXnlMuev3gMUhP3qJV/Q/iNVMJ5qIqtC6jjHQSn4RWNIAGCqt BUJZ2KnBFbjsQ== 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.98.2) (envelope-from ) id 1xGEFS-00000001qvN-0l8F; Mon, 12 Oct 2026 11:31:18 +0000 Date: Mon, 12 Oct 2026 12:31:17 +0100 Message-ID: <861p9v2m0q.wl-maz@kernel.org> From: Marc Zyngier To: Yize Wang Cc: , , , , , , , , , , , , , Subject: Re: [RESEND][PATCH 0/2] Batch register access for live migration optimization In-Reply-To: <6890def8-168d-4951-b6bd-bcbbcbf3595a@huawei.com> References: <20260918081930.4014735-1-wangyize7@huawei.com> <861paq69te.wl-maz@kernel.org> <86ece63kes.wl-maz@kernel.org> <6890def8-168d-4951-b6bd-bcbbcbf3595a@huawei.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/30.1 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: wangyize7@huawei.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, mark.rutland@arm.com, zhengchuan@huawei.com, jiangjiacheng@huawei.com, yize_w1110@163.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 08 Oct 2026 13:50:57 +0100, Yize Wang wrote: >=20 >=20 > =E5=9C=A8 2026/10/3 22:53, Marc Zyngier =E5=86=99=E9=81=93: > > On Sun, 20 Sep 2026 10:15:25 +0100, > > Yize Wang wrote: > >> =E5=9C=A8 2026/9/18 20:08, Marc Zyngier =E5=86=99=E9=81=93: > >>> On Fri, 18 Sep 2026 09:18:13 +0100, > >>> Yize Wang wrote: > >> =C2=A0 These patches focus on optimizing GICv3 register access during= live > >> migration. We found that there are a large number of locks (kvm->lock, > >> vcpus, config_lock) in the GIC, these lock operations wil cost large > >> time waste. The batches of sysreg for vcpu optimization will come in > >> follow as a separate series. And let me address these questions one by > >> one. > > All these locks should be non-blocking by the time you save anything > > related to the GIC, because: > >=20 > > - none of the vcpu can be running > >=20 > > - this must be a single threaded operation > >=20 > > So if you are seeing anything contended, this is either the sign of a > > bad KVM bug, or an indication that you are violating the above > > requirements. > >=20 > > M. >=20 >=20 > Hi, Marc! Thanks for your review. >=20 > You are right that when saving the GIC state during live migration > process, all vCPUs are not running and it is a single threaded > operation. Our patches process the packaged register states from the > userspace under the same lock. These operations only aim to reduce > the lock opreation downtime and do not involve lock contention. OK, so your argument was actively misleading, since you were claiming that locks were the majority of the overhead, and are now advocating... something else. > In addition, these patches focus on reducing the syscalls of > ioctl. Now, every register requires an ioctl, resulting in (num_cpu > * registers_per_cpu) system calls. This will cost lots of time > during the large-scale VM migration. Our patches batch registers by > category in qemu and then send them to kernel in batches. This > operations significantly reduce the number of ioctl syscalls and > save a great amount of downtime. I've suggested you use io_uring, and you completely disregarded my suggestion based on... locking contention. How do you expect me to take you seriously? I've now marked this series as rejected. Please come back once you and your AI toy have agreed on what you want to do. Thanks, M. --=20 Without deviation from the norm, progress is not possible.