From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r3-18.sinamail.sina.com.cn (r3-18.sinamail.sina.com.cn [202.108.3.18]) (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 03633305E2F for ; Wed, 19 Nov 2025 21:49:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763588961; cv=none; b=PN4iaGUfFicaxp7vxg7Dm1bHQehUfGHJ9SuYtv71WRq6mjn6vbNIyD5wo+JzhDeU8fRtDgI4J+mKA/4En8ovdH8BC2RKOFg13k5aR0ze5UkaSXqiSIWyxDEFKxaxazf4ywWpokpXRGZe4UAJLOwUVgeB/Q6XWF5ugueLeqnaJdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763588961; c=relaxed/simple; bh=C4b1DoXUEIMEK6NtZcPdY25aMH1GXnNN+lx5oZkwseQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PaSJLW7y6oNpDUKf+s7uto7Tol5koNpsfiwOmyE8Drsc6erfuorsvg7wZ22WmvruGHytj8sq+Dbuel2WS8JL6cEN0bb/JHTxKLxGCfyNOe56/+ZIa/WnfxQkMs//vShdsOyy+uRdhoLGjDEezrvdak+ylqlRJ+b3rK9Tn8cjKjE= 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=sv9sKXA7; arc=none smtp.client-ip=202.108.3.18 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="sv9sKXA7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1763588957; bh=MsSCNU3i5HpLPIkhFvphO9JO4VPGRssXKwE5J/uD+eo=; h=From:Subject:Date:Message-ID; b=sv9sKXA7sIFuqE1GhG307uTBZVS6EkCJHbbbu36WC+bLl/FmotGnlpa92N1kc0U0s YJtnN6xtvjPJWWIzI1zDfIJ9E/Dh+qXUsc9wC/SG43yFKuxOYblIYaqmytUqLgyzGI 7opNeNuHO83XbIGFxpNr3hK3qaEg8q1w1wuNZ6Tg= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.57.85]) by sina.com (10.54.253.32) with ESMTP id 691E3B5100006887; Wed, 20 Nov 2025 05:49:07 +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: 5895824456601 X-SMAIL-UIID: 76EF0D2274AF4FFDBCAB3302AD7C0657-20251120-054907-1 From: Hillf Danton To: Shrikanth Hegde Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, seanjc@google.com, kprateek.nayak@amd.com Subject: Re: [PATCH 01/17] sched/docs: Document cpu_paravirt_mask and Paravirt CPU concept Date: Thu, 20 Nov 2025 05:48:56 +0800 Message-ID: <20251119214857.9436-1-hdanton@sina.com> In-Reply-To: <20251119124449.1149616-2-sshegde@linux.ibm.com> References: <20251119124449.1149616-1-sshegde@linux.ibm.com> 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, 19 Nov 2025 18:14:33 +0530 Shrikanth Hegde wrote: > Add documentation for new cpumask called cpu_paravirt_mask. This could > help users in understanding what this mask and the concept behind it. > > Signed-off-by: Shrikanth Hegde > --- > Documentation/scheduler/sched-arch.rst | 37 ++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/scheduler/sched-arch.rst b/Documentation/scheduler/sched-arch.rst > index ed07efea7d02..6972c295013d 100644 > --- a/Documentation/scheduler/sched-arch.rst > +++ b/Documentation/scheduler/sched-arch.rst > @@ -62,6 +62,43 @@ Your cpu_idle routines need to obey the following rules: > arch/x86/kernel/process.c has examples of both polling and > sleeping idle functions. > > +Paravirt CPUs > +============= > + > +Under virtualised environments it is possible to overcommit CPU resources. > +i.e sum of virtual CPU(vCPU) of all VM's is greater than number of physical > +CPUs(pCPU). Under such conditions when all or many VM's have high utilization, > +hypervisor won't be able to satisfy the CPU requirement and has to context > +switch within or across VM. i.e hypervisor need to preempt one vCPU to run > +another. This is called vCPU preemption. This is more expensive compared to > +task context switch within a vCPU. > + What is missing is 1) vCPU preemption is X% more expensive compared to task context switch within a vCPU. > +In such cases it is better that VM's co-ordinate among themselves and ask for > +less CPU by not using some of the vCPUs. Such vCPUs where workload can be > +avoided at the moment for less vCPU preemption are called as "Paravirt CPUs". > +Note that when the pCPU contention goes away, these vCPUs can be used again > +by the workload. > + 2) given X, how to work out Y, the number of Paravirt CPUs for the simple scenario like 8 pCPUs and 16 vCPUs (8 vCPUs from VM1, 8 vCPUs from VM2)? > +Arch need to set/unset the specific vCPU in cpu_paravirt_mask. When set, avoid > +that vCPU and when unset, use it as usual. > + > +Scheduler will try to avoid paravirt vCPUs as much as it can. > +This is achieved by > +1. Not selecting paravirt CPU at wakeup. > +2. Push the task away from paravirt CPU at tick. > +3. Not selecting paravirt CPU at load balance. > + > +This works only for SCHED_RT and SCHED_NORMAL. SCHED_EXT and userspace can make > +choices accordingly using cpu_paravirt_mask. > + > +/sys/devices/system/cpu/paravirt prints the current cpu_paravirt_mask in > +cpulist format. > + > +Notes: > +1. A task pinned only on paravirt CPUs will continue to run there. > +2. This feature is available under CONFIG_PARAVIRT > +3. Refer to PowerPC for architecure implementation side. > +4. Doesn't push out any task running on isolated CPUs. > > Possible arch/ problems > ======================= > -- > 2.47.3