From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-164.sinamail.sina.com.cn (mail3-164.sinamail.sina.com.cn [202.108.3.164]) (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 0165228E0 for ; Thu, 9 Apr 2026 05:16:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.164 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775711766; cv=none; b=GyIJMeZFUVleI95WGj3YUtznJVILg+KL7dCRi3GTG1rqsXuO8+zQMd6FWj4BMqwMYUYLHHe92Xngcd0rlmNG/YZABGdOJfaoTmaY+IavTYgjSplvHNgB+LykSIsm/UrHe7i4RZzdBrMXdbDKQItekgX7kxZDvhw9E9rb+xxT8KU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775711766; c=relaxed/simple; bh=CJjmsLbOEzONxddPbi5AlwRNn+8U0dyu2Cymre6b62A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Euvv0JdLqptWs/cwRL1ZugY4W2KcdNuQtfYu4ujKas5/Tye/vSROIwB+ygezIaRG5tC7wH8uP33KdfwDEhcCtbRrjMo6A6Oy8ezY+E9XkSPsYkWAHwn2MrrWo0N5QnUu4IXND8ZQfUrVE9M26DW/mqyNER/MYCkqcjm+pIwOMXY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=SDGTVDKC; arc=none smtp.client-ip=202.108.3.164 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="SDGTVDKC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1775711762; bh=EpanJi6JKPN60q9u9VoMQHwiNccrzctNdB5TWS/Y2+E=; h=From:Subject:Date:Message-ID; b=SDGTVDKCzpJ74eCxbDjGidOQ4sk+svBp0pLvnAUzRm2mX5j5pG7phpAm2jH3JQqqk toCbuczZ0Kj5M3ldreesJh5ynblXkQtRuSzAeW83Jg9bMUdP3B5rBbew9XDIxqwcyD SdzRdBL4w8j0xsEG4KhwashFpOgEpfKJ3wkaYxLA= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.62.144]) by sina.com (10.54.253.32) with ESMTP id 69D7360600000701; Thu, 9 Apr 2026 13:15:52 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 3754894457021 X-SMAIL-UIID: 34EA2BBF494448EE9FBA8E8C0B89D69A-20260409-131552-1 From: Hillf Danton To: Shrikanth Hegde Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, Sean Christopherson , vincent.guittot@linaro.org, yury.norov@gmail.com, kprateek.nayak@amd.com Subject: Re: [PATCH v2 00/17] sched/paravirt: Introduce cpu_preferred_mask and steal-driven vCPU backoff Date: Thu, 9 Apr 2026 13:15:21 +0800 Message-ID: <20260409051556.1637-1-hdanton@sina.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 8 Apr 2026 19:19:05 +0530 Shrikanth Hegde wrote: >On 4/8/26 3:44 PM, Hillf Danton wrote: >> On Wed, 8 Apr 2026 00:49:33 +0530 Shrikanth Hegde wrote: >>> Core idea is: >>> - Maintain set of CPUs which can be used by workload. It is denoted as >>> cpu_preferred_mask >>> - Periodically compute the steal time. If steal time is high/low based >>> on the thresholds, either reduce/increase the preferred CPUs. >>> - If a CPU is marked as non-preferred, push the task running on it if >>> possible. >>> - Use this CPU state in wakeup and load balance to ensure tasks run >>> within preferred CPUs. >>> >>> For the host kernel, there is no steal time, so no changes to its preferred >>> CPUs. So series would affect only the guest kernels. >>> >> Changes are added to guest in order to detect if pCPU is overloaded, and if >> that is true (I mean it is layer violation), why not ask the pCPU governor, >> hypervisor, to monitor the loads on pCPU and migrate vCPUs forth and back >> if necessary. >> > > AFAIK, there in no information in the host scheduler on what > each vCPU is running. It maybe holding a mutex, spinlock with irq disabled This is what layer means (particularly in the data center environment). > or maybe in interrupt context. Moving/migrating the vCPUs threads without > that knowledge will hurt the guest. And it has to ensure fairness. > We have to pay the cost for vCPU. > This has to work across different archs, some have linux as hypervisor, some > has non-linux hypervisor such as powerpc, s390. > Yeah, in the car cockpit product environment in Shenzhen Linux, Android and XYZ guests run on QNX, and your steal time approach looks half baked. > Steal time in guest is common construct in all archs. I don't think such > commonality exists in host schedulers. > > If done in guest, guest actually knows what it is running and whats more important. > It can make better decisions IMHO.