[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250527151020.GV24938@noisy.programming.kicks-ass.net>
Date: Tue, 27 May 2025 17:10:20 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
tglx@...utronix.de, yury.norov@...il.com, maddy@...ux.ibm.com,
vschneid@...hat.com, dietmar.eggemann@....com, rostedt@...dmis.org,
jstultz@...gle.com, kprateek.nayak@....com, huschle@...ux.ibm.com,
srikar@...ux.ibm.com, linux-kernel@...r.kernel.org,
linux@...musvillemoes.dk
Subject: Re: [RFC PATCH 0/5] sched: cpu parked and push current task mechanism
On Fri, May 23, 2025 at 11:44:43PM +0530, Shrikanth Hegde wrote:
> In a para-virtualised environment, there could be multiple
> overcommitted VMs. i.e sum of virtual CPUs(vCPU) > physical CPU(pCPU).
> When all such VMs request for cpu cycles at the same, it is not possible
> to serve all of them. This leads to VM level preemptions and hence the
> steal time.
>
> Bring the notion of CPU parked state which implies underlying pCPU may
> not be available for use at this time. This means it is better to avoid
> this vCPU. So when a CPU is marked as parked, one should vacate it as
> soon as it can. So it is going to dynamic at runtime and can change
> often.
You've lost me here already. Why would pCPU not be available? Simply
because it is running another vCPU? I would say this means the pCPU is
available, its just doing something else.
Not available to me means it is going offline or something like that.
> In general, task level preemption(driven by VM) is less expensive than VM
> level preemption(driven by hypervisor). So pack to less CPUs helps to
> improve the overall workload throughput/latency.
This seems to suggest you're 'parking' vCPUs, while above you seemed to
suggest pCPU. More confusion.
> cpu parking and need for cpu parking has been explained here as well [1]. Much
> of the context explained in the cover letter there applies to this
> problem context as well.
> [1]: https://lore.kernel.org/all/20250512115325.30022-1-huschle@linux.ibm.com/
Yeah, totally not following any of that either :/
Mostly I have only confusion and no idea what you're actually wanting to
do.
Powered by blists - more mailing lists