lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ